Skip to content

Add an end-to-end settlement-flow integration test (deposit prepare to settlement) #381

@greatest0fallt1me

Description

@greatest0fallt1me

Description

The settlement pipeline is covered only in isolated slices: tests/integration/billing.test.ts exercises deduction and an "End-to-End Settlement/Invoice" section with a mock Soroban client, while src/__tests__/revenueSettlementService.test.ts unit-tests batching/reconciliation. There is no single integration test that walks the full money path — deposit preparation (POST /api/vault/deposit/prepareDepositController.prepareDeposit, src/controllers/depositController.ts:56), a metered gateway call (/v1/call/:apiSlugOrId in src/routes/proxyRoutes.ts:97-99), the resulting usage event, and a settlement batch (RevenueSettlementService.runBatch, src/services/revenueSettlementService.ts:48). This issue adds that end-to-end test.

Requirements and context

  • Drive the flow through the Express app built by createApp (src/app.ts:87) using supertest, injecting in-memory dependencies (the app already accepts usageEventsRepository, vaultRepository, etc. via AppDependencies at src/app.ts:56-64).
  • Use the in-memory stores for determinism: InMemoryUsageStore/InMemorySettlementStore (src/services/usageStore.ts, src/services/settlementStore.ts) and a mock settlement client like the one already used in src/__tests__/revenueSettlementService.test.ts.
  • Assert the chain: a deposit transaction is prepared (XDR returned), a billed /v1/call records exactly one idempotent usage event (the gateway records usage non-blocking — see src/routes/proxyRoutes.ts:234-258), getUnsettledEvents() then reflects it, and runBatch() produces a completed settlement that flips events to settled via markAsSettled.
  • Reuse the JWT/auth helpers in tests/helpers/jwt.ts for authenticated requests.
  • Non-functional: the test must be hermetic (no real Horizon/Soroban/Postgres), run under npm run test:integration, and respect graceful-shutdown expectations described in README.md.

Acceptance criteria

  • A new integration test under tests/integration/ walks deposit prepare → metered /v1/call → usage event → settlement batch.
  • Exactly one usage event is recorded for a single /v1/call (idempotency upheld).
  • After runBatch(), the settlement is completed and its events are marked settled (absent from getUnsettledEvents()).
  • A below-minPayoutUsdc accumulation does NOT settle (asserts the threshold at src/services/revenueSettlementService.ts:70).
  • The test uses only in-memory/mock dependencies and passes under npm run test:integration.
  • No real network or database connections are opened.

Suggested execution

1. Fork the repo and create a branch

git checkout -b testing/e2e-settlement-flow

2. Implement changes — none in source unless a wiring gap is found.
3. Write/extend tests — add tests/integration/settlement-flow.e2e.test.ts (Jest + supertest, reusing tests/helpers/jwt.ts).
4. Test and commit

npm run lint
npm run typecheck
npm run test:integration -- settlement-flow

Example commit message

test(settlement): add end-to-end deposit-to-settlement integration test

Guidelines

Contribute toward the repo's 90%+ coverage target (README.md). Document the scenario in the test header and cross-reference SETTLEMENT_STORE_DOCUMENTATION.md. Timeframe: 96 hours.

Metadata

Metadata

Assignees

No one assigned

    Labels

    GRANTFOX OSSGrantFox OSS programMAYBE REWARDEDGrantFox — potentially rewardedOFFICIAL CAMPAIGNGrantFox official campaignadvancedHigh complexity / deep contextbackendBackend servicetestingTests and coverage

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions