[marcelsamyn]

What

• enqueueAtlasUserRefreshOnSupersede now returns early when the existing setSkipJobEnqueue test switch is on. insert-new-sources, extract-graph and the context cache already use the same switch.
• Every test in src/lib/commitments.test.ts turns that switch on, next to the setSkipEmbeddingPersistence(true) call it already makes.

Production behavior is unchanged. The switch is off unless a test turns it on.

Why

setCommitmentStatus › does not keep an explicit status change in the candidate band failed on #103 with relation "users" does not exist. That PR doesn't touch commitments.

The likely chain:

1. Marking a task done supersedes its status claim, so maybeEnqueueAtlasInvalidation enqueues an atlas refresh.
2. That loads ~/lib/queues, which starts a BullMQ Worker inside the test process.
3. In CI every test file shares one Redis, so this Worker can pick up other files' jobs. A job handler's lazy imports can land in the module cache between this file's vi.resetModules() and vi.doMock("~/utils/db").
4. A later test then gets the real useDatabase, which points at the admin postgres database. That database has no users table.

I didn't reproduce the CI race directly. The evidence that the queue path was involved:

• On main with Redis stopped, three setCommitmentStatus tests time out at the queue call.
• With this change and Redis stopped, all 20 pass, and there are no Redis connection attempts.

The other claim-writing test files never reach Redis. I checked each with the same Redis-stopped probe, so only this file needed the switch.

How to test

docker compose up -d db
pnpm exec vitest run src/lib/commitments.test.ts   # passes with Redis stopped

Status

• tsc --noEmit: pass
• ESLint and Prettier on changed files: pass
• Full Vitest run with CI's env and Postgres, Redis and MinIO up: 1,089 passed, 6 skipped

🤖 Generated with Claude Code