[bokelley]

Summary

Fixes a flaky integration test that failed on main after #7832 merged (run 36850679984, passed on re-run):

FAIL tests/integration/workos-user-deletion-race.test.ts > WorkOS webhook vs sync-users deletion
  > lets deletion finish while post-commit work waits and fences stale Slack/chapter writes
AssertionError: expected true to be false

Two tests hold a webhook's post-commit side effects open, start a credential deletion, sleep 50ms, and assert deletion has already settled. Deletion runs several real Postgres transactions, so on a slow runner it can take longer than 50ms. The test then fails even though deletion was never blocked. The WorkOS calls in this file are already in-process mocks, so WorkOS latency isn't involved.

Change

Test file only. Both tests now await deletion with the file's existing within() helper (5s deadline) while the side effects are still held, and release them in finally:

• A deletion that is merely slow passes.
• A deletion that really waits on post-commit work can't settle until the release. It fails with race did not settle within 5000ms instead of hanging.

The third 50ms check in this file (line ~887) asserts the opposite: that deletion is blocked by an in-flight writer. A slow runner can't make it fail spuriously, so it's left unchanged.

Verification

Run locally against Postgres 16 provisioned with the same steps as build-check.yml (evaluator roles, migrations 584/585 applied as the operator role). To simulate a slow runner, the Postgres container was CPU-limited with docker update --cpus:

Postgres CPU limit	Before	After
unlimited	14/14 pass	14/14 pass
0.2	14/14 pass	14/14 pass
0.1	2 failed (both 50ms checks, same assertion as CI)	14/14 pass, 4 consecutive runs

I also made deletion wait on the held side effects, to check the test still catches the real bug. The fixed test fails with race did not settle within 5000ms and doesn't hang.

Not in scope: at an extreme 0.05 CPU, bounds concurrent guarded writers below deletion-reserved pool capacity hits the production CREDENTIAL_MUTATION_ADMISSION_TIMEOUT_MS in identity-db.ts. That timeout is real application behavior under a roughly 20× slower database, and it hasn't been seen in CI, so it's left alone.

🤖 Generated with Claude Code

---

Open workspace in Conductor

[aao-secretariat]

Ladon verdict: Approve

Approve — test-only change, no blocking or medium findings.

This PR modifies a single integration test file (server/tests/integration/workos-user-deletion-race.test.ts), replacing a brittle deletionSettled flag + fixed 50ms sleep with a timeout-bounded await within(deleteIdentityCredential(...)) and releasing held side effects in a finally. The "deletion does not block on held post-commit side effects" invariant is preserved via within's 5s deadline, with post-settle assertions intact.

No production, schema, docs, dist, or changeset surface is touched. No Critical/High/Medium findings reported.

Gate checks: no no-auto-approve team match; gated_paths is false; high_risk is false. review_decision is REVIEW_REQUIRED, but row 2 only applies when gated_paths is true — it is false here, so no escalation is triggered. With zero findings, rows 1–8 do not fire; falls through to row 9 → approve.