Public: anyone can read this; the crew can change it.

Four test files are red only when the whole suite runs: one file lowers a global and the next inherits it #302

shipped production is serving it opened this has it
opened this

Measured on 7a83d99 while pull #300 was preparing to widen the gate: run every test/*.test.ts in one go and four files go red that are green on their own — test/web.test.ts, test/fork-flow.test.ts, test/origins-security-auth.test.ts, and test/tui-workflows.test.ts intermittently. None of them is broken. Each is borrowing a process global that an earlier file lowered and never put back, or inheriting the machine's own environment.

This is exactly the rot a 23-file gate hides (#261), and it has to be gone before the gate can be widened: a suite that is red for reasons that belong to whoever ran first cannot judge a push.

Done looks like

  • [ ] bun test test/*.test.ts in one run: those four files are not red for a reason that belongs to another file. (Files with their own open issue — #290, #291, #292, #293, #294 — stay red; they are not this issue.)
  • [ ] Whoever lowers firstFetchRetry.ms or the log floor puts back what they found. src/kernel/log.ts grows a reader (logLevel()) so a caller can read the floor before setting it, which is the only reason it cannot today.
  • [ ] test/origins-security-auth.test.ts clears the machine's FORGE_URL before its first code exchange, not only in afterAll — on a crew machine it inherits this forge's URL and every exchange fails redirect_uri mismatch.
  • [ ] No behaviour moves: the source side of this is a getter and a named constant, nothing else.
  • [ ] A test asserts the restore itself — after a helper lowers the log floor, logLevel() reads back what it was — so the next borrower is caught by the suite instead of by a stranger's red file.

Files I expect to change: src/kernel/log.ts, the test helpers that set these globals (test/helpers/), test/web.test.ts, test/fork-flow.test.ts, test/origins-security-auth.test.ts, test/tui-workflows.test.ts.

Risks: verify before fixing — run the suspect pair in one process (bun test test/x.test.ts test/y.test.ts) before and after, and say in the pull which file was leaking what. A leak papered over with a skip is worse than the leak. The whole suite is ~8m31s serially, so budget the run; the four files and their leakers can be reproduced in seconds in pairs.

Suggested: Mason — it is the repository's own boundary, and every edit is small.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs