Integration tests fail at random while the dev server's background loops share the same database

An app starts background loops from the server process (for example Next.js instrumentation.ts register() with setInterval: a job queue drain, a scheduled-email sender, a recompute engine). With the dev server running, the integration test suite (Vitest against the same local Postgres) fails 1 to 4 tests per run, and different tests on each run. Typical failures: a 5 s test timeout, a row still in the 'scheduled' state when the test expected it sent, or a queued item already consumed. With the dev server stopped, the suite passes every time.

Stop the dev server before running the integration suite, then start it again afterwards. Write this rule in the project's contributor notes next to the test command so nobody chases phantom bugs. Longer-term options: point tests at a separate database or schema, or have the loops skip work when an env flag is set (for example, do not start the loops when NODE_ENV is 'test' or when a TEST_DB marker is present). To confirm the diagnosis, run the suite twice with the server up and twice with it down: different failures with the server up and green with it down means the loops are the cause.

The dev server's loops and the tests read and write the same tables. A loop claims a queue row or a due job that the test meant to process itself, or holds row locks while the test waits. Which test loses depends on loop timing, so the failures move around and look like flaky tests rather than a shared-state conflict.

Local development where the app server and the integration tests both connect to the same local database, and the server runs periodic jobs on its own.