Repository navigation
queue: repo-fleet-monitor is not a registered worker — Duty 1B PR bindings cannot claim (tasks_worker_id_fkey 409) #5293
Description
Problem
The fleet monitor's Duty 1B (PR↔queue binding, agent lifecycle protocol §9 / monitor spec) requires the monitor to claim a queued task as worker repo-fleet-monitor, checkpoint the PR binding, and park the task on its open PR. That claim cannot execute: repo-fleet-monitor is not a registered row in agent.workers, so the atomic claim fails on the foreign key.
Evidence (2026-11-04, repo-fleet-monitor run 2026-11-03 22:12 CST)
$ repo-queue.py claim --queue repo-health-opencode-pilot --worker repo-fleet-monitor
repo-queue: HTTP 409 from PostgREST: {"code":"23503",
"details":"Key (worker_id)=(repo-fleet-monitor) is not present in table \"workers\"",
"message":"insert or update on table \"tasks\" violates foreign key constraint \"tasks_worker_id_fkey\""}
The task being bound was opencode task 8139 (issue #1077, open PR #1565) — verified next-claimable in its queue at the time. Two further verified bindings were blocked the same way this run (the claim verb only takes the next claimable task, and the monitor worker identity does not exist): code task 8714 (issue #3949, PR #5227) and opencode task 9103 (issue #1589, PR #1595). In each case the monitor fell back to a binding agent note on the issue; the tasks remain queued for lanes to shepherd.
Acceptance criteria
agent.workerscontains arepo-fleet-monitorrow (migration or seed, following the existing worker-row pattern).repo-queue.py claim --queue <any pilot queue> --worker repo-fleet-monitorsucceeds when a claimable task exists, and checkpoint/park/block verbs accept the monitor as the claiming worker for tasks it claimed.- A monitor binding round-trip (claim → checkpoint
pr_opened→ parkpr-bound-shepherd) is demonstrated on one queued task with an open PR, and the lane shift certifier still certifies the affected queue's lanes afterwards (the monitor's claims must not corrupt lane snapshots).
Filed by the fleet monitor per the file-the-issue rule; binding context: agent lifecycle protocol §9, monitor Duty 1B.
Activity
dezren39 commentedon Nov 4, 2026
🤖 Agent note · picked up
repo-fleet-monitoris still unregistered inagent.workersand route the fix.dezren39 commentedon Nov 4, 2026
🤖 Agent note · done
Triage verdict: CONFIRMED still-live —
repo-fleet-monitorremains unregisteredEvidence gathered this shift (2026-11-04):
tasks_worker_id_fkey(code 23503) —repo-fleet-monitoris not a row inagent.workers. Three bindings were blocked that run (opencode task 8139 / issue id: validation — Phase 10 worlds as places #1077 / PR id(web): unreferenced footnote definitions are silently deleted on save — a definitions-only document saves as an empty file #1565; code task 8714 / issue fix(aggregator): wrap /attention card header row and contain wide /item element at 390px (follow-up to #1180) #3949 / PR fix(aggregator): contain mobile overflow on attention and item cards (#3949) #5227; opencode task 9103 / issue id(ci): non-blocking benchmark regression reporting vs committed baselines (#1513) #1589 / PR id(world-compile): sanitize_file_name's containment check can never fire — split('.') parts can never equal "." or "..", so the staging guard enforces nothing #1595).Route: follow-up task 9489 (small_fix, repo-health-code-pilot) enqueued this shift — register
repo-fleet-monitorinagent.workersfollowing the existing worker-row pattern, then demonstrate one binding round-trip (claim → checkpointpr_opened→ parkpr-bound-shepherd) with the lane certifier still passing. Issue #5293 stays open underqueue/queuedfor task 9489; task 9472 completes astriaged.7 remaining items
dezren39 commentedon Nov 4, 2026
🤖 Agent note · parked
repo-fleet-monitorinagent.workersis a shared queue-identity write that belongs to the queue admin path (the laptop queue-broker / monitor operator path), not a lane claim. Per the 2026-11-04 transport note, the sandbox helper talks only to the session proxy and holds no service-role access; a lane shift must not mint a new worker identity for all pilot queues from here.pr_opened→ park round-trip from issue queue: repo-fleet-monitor is not a registered worker — Duty 1B PR bindings cannot claim (tasks_worker_id_fkey 409) #5293's acceptance and this task completes on that evidence.dezren39 commentedon Nov 4, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 4, 2026
🤖 Agent note · done
repo-fleet-monitorinagent.workersand demonstrated the claim round-triprepo-fleet-monitoron repo-health-opencode-pilot reproduced the exact 409tasks_worker_id_fkeyfrom this issue; a workers readback (laptop, service key held on laptop only) listed all existing rows —repo-fleet-monitorabsent (a separatefleet-monitorrow exists, but Duty 1B claims underrepo-fleet-monitor).pm-stack/dispatch/src/queue.ts(ensureWorker): idempotent PostgREST upsert (ignore-duplicates) executed on the laptop — POST returned 201; independent GET readback shows the row: idrepo-fleet-monitor, rolemonitor, statusidle, display name "Repo fleet monitor — queue safety net, intake, Duty 1B PR bindings".repo-queue claim --queue repo-health-opencode-pilot --worker repo-fleet-monitorclaimed task 8944, checkpoint accepted, park accepted (parked 60s, reason recorded on the task; no PR binding was asserted — that task has no PR, so thepr_openedbinding stage remains for the monitor's first real Duty 1B pass). The claim stamped no lane_id, so lane snapshots/certifier state are untouched.