Flaky test suite: auth.test.ts and pairs.test.ts fail intermittently (~1 in 5 runs)

[Miracle656]

Problem

The vitest suite fails intermittently. Same commit, same machine, no code change between runs:

run 1:  Tests  2 failed | 255 passed | 1 skipped (258)
          FAIL src/__tests__/auth.test.ts   > API key auth hook > returns 401 when no key is provided
          FAIL src/__tests__/pairs.test.ts  > POST /pairs > adds a new pair and returns 201 with pairKey
run 2:  Tests  257 passed | 1 skipped (258)
run 3:  Tests  257 passed | 1 skipped (258)
run 4:  Tests  257 passed | 1 skipped (258)

Roughly 1 run in 5. Observed on at least two different branches today, and an earlier occurrence on a different pair (auth.test.ts + networkVenueConfig.test.ts), so the set of victims varies.

Both files pass in isolation. Only the full run fails. That points at cross-file state rather than a bug in either test.

Why this is worth fixing rather than living with

It has already produced two false alarms today. In one, a full run showed 2 failures against a green main, which looks exactly like "this PR broke something" — and the natural next step is to send a contributor away to fix a bug that does not exist. Only re-running four times distinguished it.

A suite that is wrong 20% of the time trains everyone to re-run rather than investigate, which is how a real failure eventually gets waved through. Related in effect to #146: between them, a red result here currently carries almost no information.

Likely cause

Cross-file shared state. Candidates, in rough order:

• process.env mutation. Several suites set env vars (networkVenueConfig.test.ts, soroswapEnabled.test.ts, the x402 tests) and vitest runs files in parallel within one process by default, so one file's beforeEach can land while another is asserting.
• Module-level config caching. src/config.ts computes at import; whichever file imports first wins, and the order varies between runs.
• Shared Redis / API-key registry state between auth.test.ts and pairs.test.ts — both exercise the API-key hook.

Suggested execution

1. Reproduce deterministically first — run with a fixed seed / single thread and a repeated loop until it fails, so you can tell a fix from luck.
2. Find the shared state. vitest --no-file-parallelism passing while the default fails is strong evidence and takes one command.
3. Fix the isolation properly: snapshot and restore process.env per file, or make config resolution lazy rather than import-time. Prefer that over serialising the whole suite — fileParallelism: false hides the bug and slows CI.

Acceptance criteria

• The root cause is identified and named in the PR — which state, shared how — not just "added a reset"
• 20 consecutive full runs pass. Paste the evidence; this is the criterion that actually matters and it cannot be satisfied by inspection
• The fix does not simply disable parallelism, unless the PR argues why isolation is impossible here
• Any test mutating process.env restores it, and this is enforced (a shared setup file, not a convention people must remember)

Notes

• Related: Fix broken @stellar/stellar-sdk vitest mock — makes every PR look red #146 (broken @stellar/stellar-sdk mock). Different cause, same consequence — CI results you cannot trust.
• main is otherwise healthy: tsc --noEmit clean, 257 tests passing on a good run.

---

Drips Wave · Complexity: Intermediate · 100 points

---

Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk

[alexitsejames-cpu]

@alexitsejames-cpu has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintainer, can you pls assign these issue to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @alexitsejames-cpu to this issue.

[johnbiliyaminu-bit]

@johnbiliyaminu-bit has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would love to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @johnbiliyaminu-bit to this issue.

[Kriss255]

@Kriss255 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Can I work on this issue please

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Kriss255 to this issue.

[obedojukwu50-stack]

@obedojukwu50-stack has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

"Hi, I'd like to work on this issue. I've reviewed the requirements and understand the expected changes. I have experience with GitHub and [your relevant skill], and I can complete and test the changes within the Wave period."

ℹ️ Repo Maintainers: To accept this application, review their application or assign @obedojukwu50-stack to this issue.

[kiikky]

@kiikky has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on Issue #151 because the Vitest suite currently fails intermittently due to cross-file state contamination. The affected tests pass in isolation, but the full suite fails roughly one in five runs, creating false CI failures and reducing confidence in genuine test failures.

I will first reproduce the failure using the recommended approach, running the full suite repeatedly with different execution settings and comparing default parallel execution against --no-file-parallelism. I will collect concrete evidence before changing the tests so the fix addresses the actual root cause rather than masking the flakiness.

I will then trace the shared state between auth.test.ts, pairs.test.ts, and the other suites that modify environment configuration or shared API/Redis state. Particular attention will be given to process.env mutations, import-time configuration caching in src/config.ts, and any shared Redis or API-key registry state.

Once the root cause is identified, I will fix the isolation at the appropriate layer. Environment changes will be isolated and restored automatically through shared test setup rather than relying on individual tests to remember cleanup. Where configuration is currently evaluated at module import time and causes order-dependent behavior, I will adjust the configuration resolution strategy so test execution order does not determine application state.

I will avoid simply disabling file parallelism because that would hide the underlying isolation bug and unnecessarily slow the suite. The preferred solution will preserve parallel execution while guaranteeing that one test file cannot leak environment or configuration state into another.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @kiikky to this issue.

[wizard-web001]

@wizard-web001 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintainer I would like to work on the issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @wizard-web001 to this issue.