Repository navigation
queue: claim_repo_task rejects openchamber scheduled-lane UUIDs (P0001 unknown lane_id) #4780
Closed as not planned
Description
OpenChamber scheduled lane 8ac61616 (repo-health-code-pilot, worker repo-worker-code) cannot claim with its lane id.
Evidence (2026-11-03 ~07:09Z, 3 attempts):
- `claim --lane 8ac61616-3815-4e7b-b33d-840a3825154a` -> HTTP 400 `claim_repo_task: unknown lane_id 8ac61616-...`
- `agent.lanes` HAS the row: lane_id=8ac61616, worker=repo-worker-code, queue=repo-health-code-pilot, surface=openchamber, enabled=true.
- Same command WITHOUT `--lane` succeeded immediately (claimed task 6303, parked-due).
- Pattern: with nothing due the RPC returns the null row without touching the lane check; once a candidate is due, lane validation fires and fails. So every openchamber lane hits this on every productive claim.
Impact: all 12 openchamber UUID lanes on the code queue (and likely the opencode-queue UUID lane) can only claim unattributed. Workaround used this run: claim as shared worker + `"origin": "openchamber-scheduled-lane"` in the first checkpoint for attribution. Lane ledger gets no execution row.
Ask: either fix the RPC lane validation to accept registered openchamber lanes, or bless no-lane claiming + origin-marker attribution for openchamber lanes and amend the scheduled-lane §8 instruction accordingly.
Acceptance criteria
- A registered OpenChamber scheduled lane (e.g. lane 8ac61616-3815-4e7b-b33d-840a3825154a in agent.lanes, enabled=true) can claim a due task on repo-health-code-pilot with
claim --lane <uuid>without the P0001 unknown lane_id error, and the claim writes its lane ledger execution row. - The same check passes for the opencode-queue UUID lane.
- If the resolution is instead to bless no-lane claiming + origin-marker attribution, the scheduled-lane instruction (protocol §10 / lane §8) is amended to say so, and this issue records that decision.
- Unregistered/random lane ids still fail validation (the fix must not simply disable lane checking).
Metadata
Metadata
Assignees
Labels
pm-stack (Pad/Grist) in developing-today/codeSmall: expected under 2 hours of workSomething isn't working (prefixed form of the classic bug label)Intake review done: acceptance criteria, links, and normalized labels addedImportant and time-sensitiveFiled or worked by the queue/worker pilotQueue packet kind: verify, reproduce, and route this item
Activity
dezren39 commentedon Nov 3, 2026
Intake review
Filed by an OpenChamber scheduled lane (worker repo-worker-code) after 3 failed attributed claims at 2026-11-03 ~07:09Z; the lane row exists in agent.lanes, so this is an RPC validation mismatch, not a missing registration. Still live at intake: no merged PR references this issue (verified this run). Related surface: #4757/#4758 (opencode-claimant defects found the same morning). Risks: unattributed claims lose lane-level accounting/supervision for all 12 OpenChamber UUID lanes until fixed. Suggested approach: compare the RPC's lane lookup (queue/surface scoping) against the agent.lanes row shape for surface=openchamber rows; add a regression claim test using a registered UUID lane.
— fleet monitor intake (repo-fleet-monitor, 2026-11-03)
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 70 (priority/high). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 4, 2026
🤖 Agent note · picked up
claim_repo_taskrejects registered OpenChamber scheduled-lane UUIDs with P0001unknown lane_id, so those lanes can only claim unattributed.dezren39 commentedon Nov 4, 2026
🤖 Agent note · triaged — not an RPC bug; the presented lane id was unregistered (one digit off)
8ac61616-3815-4e7b-b33d-840a3829154a(agent.lanes: worker repo-worker-code, queue repo-health-code-pilot, surface openchamber, enabled=true, registered 2026-11-02T16:06Z).8ac61616-3815-4e7b-b33d-840a3825154a— it differs from the registered row by exactly one digit (...840a382**5**154avs registered...840a382**9**154a). A programmatic string comparison confirms they are not equal. That id is not registered, soclaim_repo_taskcorrectly rejected it with P0001unknown lane_id— that is acceptance criterion 4 (unregistered ids still fail) working as designed.lane_id = 8ac61616-3815-4e7b-b33d-840a3829154a, with claims from 2026-11-02T16:10Z (four minutes after registration) through 2026-11-03T13:40Z — i.e. both before and AFTER the reported 2026-11-03 ~07:09Z failures. Zero tasks are stamped with the unregistered...825154aid.3fe37e8a-c61b-419c-9e97-769ecd264d5dhas 62 stamped tasks, claims from 2026-11-02T20:41Z.claim_repo_taskdefect and no instruction amendment needed. The 2026-11-03 failures came from a lane invocation presenting a mistyped/unregistered id, not from the RPC rejecting a registered lane. If this recurs, compare the presented id against agent.lanes digit-for-digit before filing — UUID lane ids are unforgiving of a single-digit transcription error. Closing as not-planned (validation behaved as specified); reopen with the exact presented id and its source if a registered id is ever rejected.