Flow
Where the reset happens
Moving the reset to the file stops the leak.
1One copy per worker, made once
Parallel tests stay apart, but later files see earlier rows
2Fresh copy per file
Every file starts clean and pays one quick copy
3Inside one file
Tests still share that file's copy, on purpose
Flow
The per-file setup, in order
All of it runs before your code creates a database client.
1Guard
Refuse unless it's a local clone for this run and this worker
2Forced drop
Throw away the worker's database and close old connections
3Copy the template
Make the database again from the frozen template
4Point settings and add token
Every database setting moves to the new copy, with a random token in its comment
5Run the file
Only now does your code connect
Two database tests in the ordering system failed in CI with errors that made no sense together. One was a coverage check complaining about a store. The other said a one-per-store rule had been broken. Both looked like bugs in my code. Both were really old rows left by another test file.
Leftover rows on a shared worker copy
My tests run on a few workers at once. Each worker got its own copy of the database at the start of the run, so tests running side by side never saw each other's data. Good.
But each worker runs several test files in a row on that same copy, and no file cleans up. So a later file sees what earlier files wrote. This time two store fixtures from two files ended up with the same short store code. The file that ran second broke on rows it never made, and it got the blame.
The errors talked about business rules, not the tests, so they pointed straight at the wrong code.
Dropping and recopying before each file
The agent and I moved the reset from the worker to the file. Before each test file starts, setup throws away that worker's database and makes a new one from a frozen template.
That is the whole reset, and it runs before every test file.
A few details matter if you build this yourself. Make the template once, after migrations, and set it to refuse connections, because Postgres can't copy a database while anyone is connected to it. Use the forced drop so leftover connections from the last file get closed. Point every database setting at the new copy before your code creates its database client. And write a random token into the new database's comment so a test can check it got a fresh one.
Each file now pays one copy, well under a second. The tests still run in parallel.
Only this run's clone can be dropped
Code that drops databases needs a guard, and mine runs before anything gets dropped. It only accepts a local database whose name belongs to the current test run, and only the clone for the right worker. Anything else, and it refuses.
What the token test checks
Forcing the bad file order onto one worker brought back the same CI error, and that order passed after the change. A test now checks the token, checks that no stores exist yet, and checks that the template still refuses connections. Unit tests cover the guard.
Tests inside one file still share a copy, on purpose, because some of them race each other. Only the database gets reset between files.