fix(schema): drop agents_organization_id_id_key — broke ON CONFLICT (id) callers#747
Conversation
…id) callers The parallel `UNIQUE (organization_id, id)` added in 20260515120000 (PR #734 schema-prep) actively breaks `ON CONFLICT (id) DO NOTHING/UPDATE` clauses on the agents table. Why: Postgres' `ON CONFLICT (X)` only suppresses violations of the unique constraint matching exactly column set X. Adding a second unique constraint that overlaps with the PK means inserts can fail on the new constraint *before* reaching the PK conflict — and `ON CONFLICT (id)` doesn't catch it. Surfaced in `__tests__/integration/.../race-mcp` where parallel inserts of `(org-a, race-mcp-0)` started throwing `agents_organization_id_id_key` duplicates instead of being silently de-duped by the existing `ON CONFLICT (id) DO NOTHING` clause. The integration job has been red on main since #734 deployed for this exact reason. The PK on `(id)` already enforces global uniqueness, which subsumes `(organization_id, id)` uniqueness — the new constraint was logically redundant. Phase C of the per-org PK migration will swap the PK directly without needing a parallel constraint as a stepping stone. Mirrored in embedded-schema-patches.ts (idempotent DROP CONSTRAINT IF EXISTS).
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughThis PR removes the ChangesRemove conflicting agents constraint
Possibly related PRs
Poem
🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add Comment |
…_dump elided length
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Why
PR #734 added a parallel `UNIQUE (organization_id, id)` on `agents` as schema-prep for the eventual per-org PK swap. It actively broke any `ON CONFLICT (id) DO NOTHING/UPDATE` callers.
Postgres semantics: `ON CONFLICT (X)` only suppresses violations of the unique constraint matching column set X. Adding a second unique constraint that overlaps with the PK means inserts can fail on the new constraint before reaching the PK conflict — and `ON CONFLICT (id)` doesn't catch the violation of the wider one.
Surfaced in the `tests/integration/.../race-mcp` test where parallel inserts of `(org-a, race-mcp-0)` started throwing `agents_organization_id_id_key` duplicates instead of being silently de-duped:
```
PostgresError: duplicate key value violates unique constraint
"agents_organization_id_id_key"
detail: Key (organization_id, id)=(org-a, race-mcp-0) already exists.
```
CI's `integration` job has been red on `main` since #734 merged for this reason.
Fix
Drop the constraint. The PK on `(id)` already enforces global uniqueness, which strictly subsumes `(organization_id, id)` uniqueness — the new constraint was logically redundant. Phase C of the per-org PK migration will swap the PK directly without needing a parallel constraint as a stepping stone.
Mirrored in `embedded-schema-patches.ts` (idempotent `DROP CONSTRAINT IF EXISTS`).
Test plan
Summary by CodeRabbit