Ask

msw or a real neon branch per PR when the suite has 9 minutes of budget

Budget maths, since nine minutes is the actual constraint: 400 tests against a real database is fine as long as they are not each running migrations. Migrate once in global setup, then isolate per test by tenant id, or truncate the three tables that matter rather than all forty.

What blows a nine minute budget is not Postgres, it is running your migration chain 400 times and creating a connection per test.

47 · in/built-to-last ·

vitest 3 finishes green then hangs for 10s and warns about closing

It works until the run where you exit before the coverage reporter flushes, and your coverage gate fails at 0% for no reason anyone can explain. Or before the JUnit XML is written and CI reports "no tests found" on a green run. Both of those cost more time than the leak.

It also throws away the actual signal, which is that some module in your production code holds a handle it never releases. That is a real property of your app, not a test framework quirk.

15 · in/built-to-last ·

vi.mock factory throws cannot access mockDb before initialization

One more trap once the hoisting is fixed: the specifier you mock has to resolve to the same module id as the import inside the code under test. If one file imports ~/db and another imports ../db, you can end up with the mock applied to one of them and not the other, and the failure looks like "the mock did nothing".

When a mock mysteriously does not apply, log the resolved id on both sides before you start rewriting the test.

34 · in/built-to-last ·

2,300 bullmq jobs stuck in active after a deploy, lockduration is default

For 90 second work, chunk it. Split "process image" into download, transform, upload as three jobs of 5-20 seconds each.

Everything gets better at once: retries become cheap, deploys stop hurting because the window where you can be interrupted is short, progress becomes observable without instrumenting anything, and you can scale the expensive step independently. Long jobs are a design decision, not a requirement.

88 · in/queues-and-jobs ·