Repository navigation
Queue dedupe is a one-way door: a cancelled task permanently blocks re-enqueue of its issue #1298
Description
Bug (live instance found 2026-10-26, monitor run 23:19 CDT)
agent.enqueue_repo_task (migration 0008) inserts with
on conflict (dedupe_key) do nothing and then returns the existing
row — for any status, including cancelled. Combined with the
unique index on dedupe_key, a cancelled task permanently owns its
issue's work identity: the issue can never be enqueued again, and the
caller cannot tell, because enqueue returns the cancelled row as if
it had succeeded.
Live instance
- Issue id(ci): F11.4 fast CI lane under 15 minutes #551 (id-check flake leg exceeds its 60-minute cap) had an
inert shadow task 1064 (attempts 0, never worked). - The fleet monitor's safety net built a live triage packet for id(ci): F11.4 fast CI lane under 15 minutes #551
and was blocked by the dedupe wall; the operator cancelled 1064
(verifiedcancelled, reason superseded) and retried the enqueue. - The retry returned task 1064 — the cancelled shadow row — with no
new task created. Verified inagent.tasks: exactly one row exists
forrepo-health:v1:triage:developing-today/code:issue:551, status
cancelled. id(ci): F11.4 fast CI lane under 15 minutes #551 sits ownerless, and every future monitor run will
repeat the same silent no-op.
Why it matters
The monitor's Duty 1 promise is "a filed issue with the work-order
label must never sit ownerless." This bug breaks that promise
silently for any issue whose task was ever cancelled — and the
fleet cancels tasks routinely (orphans, superseded packets,
issue-closed cleanups; e.g. nix task 1172 on 2026-10-26). Any of
those issues reopening hits the same wall.
Proposed fix (pick one, migration + synthetic test like 0012)
- (a) Revive on enqueue (recommended): on conflict where the
existing row iscancelled, update it back toqueuedwith the
new payload/priority/not_before, reset result/last_error, and write
anenqueuedevent withrevived_from_cancelled: true. Smallest
schema change; keeps one row per identity; audit trail preserved. - (b) Partial unique index on
dedupe_keycovering live statuses
only — allows a second row per identity; weakens the "dedupe key
names the task" lookups the monitor relies on. - (c) An explicit
reopen_repo_taskverb — works, but every producer
must learn to call it after a failed enqueue, and the silent-no-op
shape remains for anyone who doesn't.
Decide whether failed tasks should revive the same way (probably
not — failure is a worked outcome; cancellation is an operator
decision. Record the reasoning either way).
Acceptance criteria
- Synthetic test: enqueue → cancel → enqueue same key returns a
livequeuedtask (revival event present); enqueue →
enqueue (live) still returns the existing row unchanged. - id(ci): F11.4 fast CI lane under 15 minutes #551's triage packet enqueues successfully to
repo-health-code-pilot and is claimable. - The helper/monitor can distinguish "enqueued new", "already
live", and "revived" from the returned row + events.
Child of epic #1233. Filed by Muse (operator) 2026-10-27, from the
fleet monitor's #551 flag.
Activity
developing-today commentedon Oct 27, 2026
CODE-420
dezren39 commentedon Oct 27, 2026
Correction to the live instance (2026-10-27, Lane B shift): #551 is not wholly ownerless. A
small_fixtask for the same issue (task 1283) exists under a different dedupe key (the key embeds the packet kind:...:triage:...vs the small_fix key) and is progressing — parked with measurements posted (comment 6434473452). What remains blocked is specifically the triage/ci-investigation packet, whose key is owned by the cancelled shadow task 1064. The bug and the silent-no-op behavior stand exactly as filed; only the "sits ownerless" framing should read "this packet can never be enqueued."dezren39 commentedon Oct 27, 2026
🤖 Agent note · filed
queue/queuedwith no live pilot task (cancelled shadow task 1354 holds its dedupe key). The monitor'srepo-queue.py enqueue --queue repo-health-code-pilotreturned task 1354 (queuerepo-health-code-shadow, statuscancelled) and created nothing in the pilot queue — verified by direct live-queue query immediately after. The issue remains ownerless through no producer's fault. This is the second live consequence class for the one-way door (a wrong-queue first attempt, not just a cancelled pilot task).4 remaining items
dezren39 commentedon Oct 27, 2026
🤖 Agent note · picked up
dezren39 commentedon Oct 27, 2026
🤖 Agent note · done — revive-on-enqueue implemented, applied, and proven (queue task 1392)
0014_revive_on_enqueue.sql(in~/workspace/supabase/muse-dev/migrations/, committed ada0e81) re-creates bothagent.enqueue_repo_taskandagent.enqueue_repo_task_fleetwith option (a) from this issue: on conflict where the existing row iscancelled, the row revives in place toqueuedwith the new queue/title/body/payload/priority/not_before/max_attempts, attempts reset to 0, result/last_error/worker/lease/claim/completion state cleared, and anenqueuedevent is written withrevived_from_cancelled: true. Enqueued-new = event without the flag; already-live = no new event and the row returned unchanged; revived = event with the flag — the three cases are distinguishable from the returned row + events.failedtasks deliberately do NOT revive — failure is a worked outcome whose accounting (attempts, last_error, result) producers and the monitor rely on; cancellation is an operator decision, so revival matches operator intent. Reasoning is recorded in the migration header.0014_revive_on_enqueue_test.sqlrun live against muse-dev — enqueue → duplicate enqueue returned the same row (task 1466) unchanged → cancel → enqueue returned the same row livequeuedwith the new packet (title/priority replaced, state reset) and the event trailenqueued → cancelled → enqueued (revived_from_cancelled: true). The synthetic task was cancelled as cleanup afterwards.repo-queue.py healthread still succeeds.