Skip to content

feat: backpressure tests, RPC health checks & batch conditional tests (#866 #867 #868) - #959

Open
udokaamoni wants to merge 5 commits into
AtomicIP:mainfrom
udokaamoni:feat/issues-866-867-868
Open

feat: backpressure tests, RPC health checks & batch conditional tests (#866 #867 #868)#959
udokaamoni wants to merge 5 commits into
AtomicIP:mainfrom
udokaamoni:feat/issues-866-867-868

Conversation

@udokaamoni

Copy link
Copy Markdown

Summary

This PR resolves three issues across the api-server and JS batch modules.


#866 — Add request_queue.rs backpressure test under RPC latency

  • Fixed a correctness bug in acquire(): queue_size was only incremented after winning a semaphore permit, so waiting requests were invisible to the depth counter. Now reserves the slot on entry and releases on timeout/rejection — making backpressure accurate.
  • Registered request_queue module in lib.rs (was missing; tests weren't being discovered).
  • Added 3 new tests:
    • test_backpressure_under_simulated_rpc_latency — fills queue 5/5, asserts 6th rejected with 503
    • test_queue_depth_and_rejection_limits_under_rpc_latency — single-concurrency, fills 3/3, confirms overflow rejection
    • test_request_timeout_under_high_rpc_latency — 200ms timeout with 1s holder confirms 408
  • Updated docs/api-reference.md with Soroban RPC latency table (50ms–2000ms by operation type), queue limits, and client retry guidance.

closes #866


#867 — Add health.rs checks for Soroban RPC reachability

  • Added check_rpc_reachability_with_params(latency_ms, is_circuit_open, is_reachable) for fully testable RPC probing without real network calls.
  • Added soroban_rpc field to ComponentHealth response to explicitly surface RPC dependency health separately from process health.
  • Three clearly distinguished states:
    • healthy — RPC reachable, latency < 2000ms, circuit closed
    • degraded — RPC slow (≥2000ms), circuit breaker OPEN, or unreachable
    • down — API process itself failing (memory/disk critical, OOM)
  • /health returns HTTP 200 for healthy and degraded, HTTP 503 only for down.
  • 6 new tests covering every health state.

closes #867


#868 — Add missing test suite for batchConditionalCompletion.js

  • Added src/__tests__/batchConditionalCompletion.test.js (343 lines).
  • Covers:
    • All 4 condition types: KEY_VALID, PRICE_BELOW, TIME_AFTER, CUSTOM
    • Input validation: non-array, empty, exceeds MAX_BATCH_SIZE, missing swapId, bad price, non-array conditions
    • Compound multi-condition logic (all pass / any fail)
    • Partial-batch success: mixed COMPLETED/SKIPPED in same batch
    • Invalid-condition error recording without throwing
    • filterEligibleSwaps and isSwapEligible helpers
  • Matches conventions of existing batchCanceller.test.js and batchDisputeResolver.test.js.

closes #868

…P#866

- Fix acquire() to increment queue_size before blocking on semaphore,
  so waiting requests are counted in queue depth immediately (not only
  after winning a permit)
- Add test_backpressure_under_simulated_rpc_latency: fills queue to
  max (5/5) with 2 active + 3 waiting requests, asserts 6th is
  rejected with 503 SERVICE_UNAVAILABLE
- Add test_queue_depth_and_rejection_limits_under_rpc_latency: single-
  concurrency queue, fills to 3/3, confirms overflow rejection
- Add test_request_timeout_under_high_rpc_latency: 200ms timeout with
  a 1s holder confirms 408 REQUEST_TIMEOUT for waiters
- Register request_queue module in lib.rs so tests are discovered
- Replace fixed sleep(20ms) with retry loop to eliminate race flakiness

closes AtomicIP#866
…tomicIP#867

- Add check_rpc_reachability_with_params() to HealthChecker for
  testable RPC probe with explicit latency_ms, circuit_open, reachable
- Add set_rpc_endpoint() to configure the target Soroban RPC URL
- Expose soroban_rpc field in ComponentHealth response (mirrors
  contract_connectivity for explicit dependency health surfacing)
- get_health() now distinguishes three states:
    healthy  — RPC reachable, latency < 2000ms, no circuit open
    degraded — RPC slow (>=2000ms), circuit breaker OPEN, or unreachable
    down     — API process itself failing (memory/disk critical, OOM)
- health_handler returns 200 for both healthy and degraded (RPC issues
  do not take the API process down), 503 only for down
- Tests added: test_health_state_healthy, _degraded_rpc_slow,
  _degraded_circuit_open, _degraded_rpc_unreachable,
  _down_process_failing, _down_critical_component (all passing)

closes AtomicIP#867


- Add 'Request Queuing, Backpressure & RPC Latency Expectations'
  section documenting the request_queue.rs behaviour
- Table of Soroban RPC latency ranges by operation type
  (50ms–200ms reads up to 1000ms–2000ms+ transaction submission)
- Document max_queue_size (1000), max_concurrent_requests (100),
  request_timeout (30s) defaults and HTTP response codes (503, 408)
- Client retry guidance: exponential backoff with jitter on 503/408

closes AtomicIP#866
…omicIP#868

- Add src/__tests__/batchConditionalCompletion.test.js (343 lines)
- Covers all four condition types: KEY_VALID, PRICE_BELOW, TIME_AFTER,
  CUSTOM (predicate function, truthy/falsy, type errors)
- Input validation paths: non-array, empty array, exceeds MAX_BATCH_SIZE,
  missing swapId, non-positive price, non-array conditions
- evaluateSwapConditions compound logic: no-conditions eligible, all
  pass, any fail, invalid condition type throws
- Partial-batch success: mixed COMPLETED/SKIPPED in same batch,
  all-COMPLETED, all-SKIPPED outcomes
- Invalid-condition error handling: unknown type and bad threshold
  type recorded as failed entries without throwing
- filterEligibleSwaps and isSwapEligible helper coverage
- Matches conventions of existing batch*.test.js files (Jest describe/
  test, deterministic nowMs via ctx, validSwap factory helper)

closes AtomicIP#868
@drips-wave

drips-wave Bot commented Aug 29, 2026

Copy link
Copy Markdown

@udokaamoni Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant