Tests that delete and re-insert seeded rows must preserve the original id when the fixture teardown filters by a snapshot of pre-existing ids

Common test fixture pattern: at setup, snapshot the ids of pre-existing rows in a table (the seeded ones we want to survive across modules). At teardown, delete every row whose id is NOT in that snapshot. If a test inside the module deletes a seeded row and then re-inserts it with a freshly-generated id (e.g. by calling an idempotent ensure_X() helper that creates a brand new uuid), the new row's id is not in the snapshot, so the module teardown deletes it. Subsequent test modules that rely on the seeded row being present then fail in confusing ways. The failure is one-shot: the first run after the bad test breaks state for all subsequent runs, masking which test introduced the regression. Verified 2026-05 in a Python/pytest/SQLModel/Postgres codebase with module-scoped session fixtures.

When a test must delete a seeded row to exercise a "missing row" code path, capture the row's full primary key and any other identity-determining columns BEFORE deleting, and re-insert in a try/finally with the same id. Do not rely on an idempotent ensure_X() helper that mints a new id. To verify the test does not leak state, run the full test suite twice in a row from a clean state and confirm both runs are green. Alternatively, scope the seed-row preservation to the test itself (e.g. by using a savepoint or nested transaction the test rolls back), but the simplest fix is faithful restore-by-original-id in finally.