Public: anyone can read this; the crew can change it.
Flaky: test/subscriptions.test.ts #2126
Check · Review · Land · Live done — Landed and live in production.
`test/subscriptions.test.ts` now passes in any order, and its row has moved out of `EXCLUDED` in `scripts/gate.ts`. All ten red seeds from the issue are green. `bun x tsc --noEmit` is clean. I ran only this file's tests, not the whole check.
shipped production is serving it deploy 93e874d
Test-only change, no user-facing surface. test/subscriptions.test.ts now passes three runs in a row here (16 pass) and tsc is clean. Each pool test builds its own data dir and app, and the tests no longer depend on the ones before them: pool() and account() create the accounts they need, the empty-pool test deletes what is there, and the headroom tests set the value they assert. The file is admitted to the gate by removing its EXCLUDED entry. I did not open the preview; nothing user-facing changed.
Two things to do next: (1) the pull never says what the flake was, so name the cause in the description; (2) the file takes about 15s, and the 60s timeouts on the run tests hide how slow the fake provider is, so measure it and tighten them.
test/subscriptions.test.tsnow passes in any order, and its row has moved out ofEXCLUDEDinscripts/gate.ts. All ten red seeds from the issue are green.bun x tsc --noEmitis clean. I ran only this file's tests, not the whole check.Flake-hunt record (
bun scripts/flake-hunt.ts admit test/subscriptions.test.ts): 10/10 green, random order, under load. The seeds were 1888477164, 3428596838, 1849122840, 869404394, 2194451630, 2045487699, 530102959, 590350282, 3492342971 and 3986297113.Cause: the tests in each
describeshared one app and one database, and later tests read what earlier ones had added.What changed, all in the test file except the gate row:
beforeEach/afterEach). The rotation test adds its own "Personal" account instead of finding the one the first test left.pool()helper gets or adds the two accounts, wakes them and re-grants them.- The "rests the account" test counts invocations from where they started instead of assuming 1 and 2. - The "holds a run" test rests both accounts itself.
- An
account()helper gets or adds the "work" account. - The headroom tests set the 0 and 25 values they assert on. - The "adds an account" test starts by emptying the pool, since it asserts the empty-state copy.Not done: the app source is untouched, since the bug was in the test setup, not the app. No assertions were weakened and no retries were added.
Closes #2113