Repository navigation
repo-queue: enqueue dedupe matches terminal rows — a completed dedupe key can never be re-enqueued, silently orphaning follow-ups #2323
Description
Bug (proven live 2026-10-29, operator queue repair)
The enqueue RPC behind ~/tools/repo-queue.py (agent.enqueue_repo_task) dedupes on dedupe_key against all rows regardless of status and returns the existing row. For a done (completed) task that means the key is permanently poisoned: any later packet for the same issue — a re-triage, a planned follow-up round — silently returns the completed row, creates nothing, and mutates nothing. The caller cannot tell; enqueue "succeeds."
This is the completion-side sibling of #1298 (cancelled rows), fixed 2026-10-27 by migration 0014_revive_on_enqueue.sql for cancelled rows only. done rows were not covered, and the assumption recorded in several task completion notes — "the dedupe key frees on completion" — is false as the RPC behaves today. (Related queue-lifecycle gap: #1337, the missing claim/park verb.)
Evidence (fresh reads before/after, 2026-10-29)
Seven Duty-1-style re-triage packets were built for open issues whose queue/queued labels promised work, and each enqueue was attempted:
| Issue | Returned existing task | Its status | New task created |
|---|---|---|---|
| #553 | 1261 | done | none |
| #785 | 2209 | done | none |
| #788 | 2214 | done | none |
| #806 | 2245 | done | none |
| #961 | 2298 | done | none |
| #1342 | 1327 | done | none |
| #1058 | 2328 | done | none |
The done rows' updated_at values were byte-identical before/after each attempt; a final count shows 0 live tasks across all seven dedupe keys while all seven issues sit open with queue/queued labels.
Consequences already observed
- id(world): F11.7 host metrics, Prometheus endpoint and tracing spans #553 (priority/high): triage 1261 done → fix 1305 done (slice 1 merged, PR feat(id): F11.7 slice 1 — host metrics core + world stats surfacing (#553) #1437). Task 1305's planned "combined slices 2+3 follow-up" enqueue silently no-opped; the remaining acceptance criteria (Prometheus endpoint + tracing spans) are unowned.
- id: Phase 13 F13.3 SSH-over-iroh reachability (and iroh-over-SSH fallback) #785: triage 2209 done; the iroh-over-SSH fallback — an explicit acceptance criterion — has no code, and its planned follow-up packet was never enqueued (same silent no-op, recorded in 2209's own completion note).
- docs(usage-hub): dashboard documentation completeness — research provenance links + candidate cards #1058: the real fix task 2992 was cancelled as a "duplicate of task 2329" on the strength of this behavior plus a phantom reference — task 2328's recorded
follow_up_task_ids [2329]is erroneous (2329 is an unrelated nix triage for mcpx: the permissive auth interface authorizes everyone — real validation for the conformance rows that require refusal dezren39/darwin-nix#300). The fix for docs(usage-hub): dashboard documentation completeness — research provenance links + candidate cards #1058 never ran.
Per-issue state of the seven blocked issues
- id(world): F11.7 host metrics, Prometheus endpoint and tracing spans #553 OPEN, priority/high — slice 1 merged (PR feat(id): F11.7 slice 1 — host metrics core + world stats surfacing (#553) #1437); slices 2+3 follow-up never enqueued.
- id: Phase 13 F13.3 SSH-over-iroh reachability (and iroh-over-SSH fallback) #785 OPEN — SSH-over-iroh tunnel exists; iroh-over-SSH fallback criterion unimplemented.
- id: Phase 13 F13.6 native client shells on the shell contract #788 OPEN (XL) — disposition was re-queue gated on id: Phase 12 designs to run through the research workflow #534 + id: native client shells and client capabilities #538; both gates re-verified still OPEN 2026-10-29.
- id: F12.13 journal replication (read replicas over a signed stream) #806 OPEN — re-queue gated on F12.6/id: Phase 12 designs to run through the research workflow #534 + F11.12; id: Phase 12 designs to run through the research workflow #534 re-verified still OPEN.
- mcpx fleet config: gopls to worktree scope + live workspace proof #961 OPEN, status:blocked — requeue after mcpx: initialize sends rootUri/workspaceFolders for scope-resolved instances #959 lands; mcpx: initialize sends rootUri/workspaceFolders for scope-resolved instances #959 re-verified still OPEN.
- Controlled pool tests: A/B real task batches before any pool change lands #1342 OPEN — all three acceptance criteria appear covered (tasks 1327 triage, 1670 slice 1, 1671 slice 2 under pool flag: add Kimi K3.1 Pro via opencode-go to summit — AA 55, plan door found (models.dev Go catalog + 53/57 measured probe successes), $2.11/task #1409's key); needs only a close-out triage once enqueue works.
- docs(usage-hub): dashboard documentation completeness — research provenance links + candidate cards #1058 OPEN — fix never ran (see phantom-reference finding above); the re-triage must also correct the phantom
follow_up_task_idsreference on the record.
Fix options
- Root fix (recommended): the enqueue RPC dedupes only against non-terminal rows (queued / claimed / parked / blocked). A key matching only a completed (or cancelled — already revived in place per Queue dedupe is a one-way door: a cancelled task permanently blocks re-enqueue of its issue #1298's migration 0014) row produces a fresh queued task. This is the semantics workers and the fleet monitor already assume everywhere.
- Pattern-side alternative: extend the dedupe design patterns with a round suffix (e.g.
repo-health:v1:triage:developing-today/code:issue:553:r2). No schema change, but every producer (lanes, creators, monitor, dispatcher) must learn the convention, round bookkeeping becomes a new failure surface, and already-poisoned base keys stay poisoned.
Acceptance criteria
- After the fix, enqueueing a packet whose
dedupe_keymatches only adonetask creates a new queued task. - Enqueueing a packet whose key matches a live task (queued/claimed/parked/blocked) still returns the live task — no duplicates.
- The seven blocked issues above (id(world): F11.7 host metrics, Prometheus endpoint and tracing spans #553, id: Phase 13 F13.3 SSH-over-iroh reachability (and iroh-over-SSH fallback) #785, id: Phase 13 F13.6 native client shells on the shell contract #788, id: F12.13 journal replication (read replicas over a signed stream) #806, mcpx fleet config: gopls to worktree scope + live workspace proof #961, Controlled pool tests: A/B real task batches before any pool change lands #1342, docs(usage-hub): dashboard documentation completeness — research provenance links + candidate cards #1058) can be re-triaged; their re-triage packets will be rebuilt by the fleet monitor's Duty 1 once enqueue works.
- A regression test or documented probe (migration-style synthetic test, like the one for Queue dedupe is a one-way door: a cancelled task permanently blocks re-enqueue of its issue #1298/0014) covers both directions: terminal-key re-enqueue creates, live-key enqueue dedupes.
- The chosen semantics are written down where producers will see them (queue tooling docs / protocol), retiring the false "key frees on completion" assumption explicitly if option 1 lands differently than expected.
Activity
developing-today commentedon Oct 29, 2026
CODE-1173
dezren39 commentedon Oct 29, 2026
🤖 Agent note · filed
dezren39 commentedon Oct 30, 2026
Live instance (2026-10-30, lane B worker shift): task 3170 completed with PR #2570 merged for issue #1911, leaving a recorded remainder (script.check pipeline) with a ready packet (
packet-1911-script-check-remainder.json).repo-queue.py enqueuewith the standard fix key returned the DONE task 3170 row (rc=0) and created no follow-up task — the remainder is orphaned exactly as this issue describes, and now waits on this fix (or a producer re-scoping it under a new issue). Workaround attempts rejected by the validator: suffixed fix keys match no design pattern;maintenancefamily is not valid for kindsmall_fix.dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
6 remaining items
dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 1, 2026
🤖 Agent note · done (triage routed)
repo-queue.py enqueue(no --worker flag exists or is needed) enqueued both follow-ups this shift.repo-health:v1:fix:developing-today/code:issue:2323) carrying the pinned semantics from the finding: new row after done with history preserved, exactly one live task per key under concurrent enqueues, 0014/0015 fleet cancelled-revival preserved, the global(dedupe_key)index reconciled together with both RPC definitions in one atomic muse-dev migration, transactional regression tests for all four behaviors. First step named in the packet: read the LIVE pilot definition + the actual index (0015 states the fleet function is byte-identical to live and does not change the pilot function; the pilot definition is not in local files).hidden_files/packet-2323-fix.jsondezren39 commentedon Nov 1, 2026
🤖 Agent note · done (fix landed)
supabase/muse-dev/migrations/0019_enqueue_dedupe_live_rows.sql) and applied live via the Supabase Management API.UNIQUE (dedupe_key)constraint dropped; replaced by partial unique indextasks_dedupe_key_live_keyover live rows:queued/claimed/parked/blocked/needs_review/cancelled(needs_review = non-terminal, documented in the migration;failedtreated as terminal likedone;cancelledis in the index because 0014 revival is conflict-driven — a first dry run without it proved revival never fires).agent.enqueue_repo_taskandagent.enqueue_repo_task_fleetrebuilt from their LIVEpg_get_functiondefbodies, edited only in the dedupe machinery: insert targets the partial index; fallthrough returns the live row, else revives the newest cancelled row in place (0014 semantics, leases cleared, event logged), else returns the newest row for the key.pg_get_functiondef). 0019 deliberately preserves the live list; applying 0015 remains its own decision.