Repository navigation
queue: coverage join ignores open fix PRs — issues get re-triaged while their PRs bit-rot (#941, #1204, #1207) #4951
Description
Finding
Three coverage-pass triage packets claimed tonight that their issue "had no live queue task", because the coverage join (coverage/issues-code-live.json vs agent.tasks, checked 2026-11-03T12:36Z) matches issues to tasks through queued/claimed state only. All three issues already had an open fix PR from a completed queue task, and all three PRs are now far behind main — two of them no longer merge at all:
| issue | triage packet | prior triage | fix PR | branch | ahead / behind main | merges? |
|---|---|---|---|---|---|---|
| #941 | task 7600 | task 1088 (2026-10-31) | #4832 | queue/4642-941-operator-token-comments |
2 / 138 | yes (clean, unmerged) |
| #1207 | task 7653 | task 2485 (2026-11-01) | #3958 | queue/4917-1207-roadmap-horizon |
1 / 1554 | no — conflict in pm-stack/aggregator/src/render.ts |
| #1204 | task 7655 | task 2482 (2026-11-01) | #3957 | queue/4914-1204-extractor-health |
3 / 1547 | no — conflict in pm-stack/aggregator/src/saas-extract.ts |
(git merge-tree --write-tree origin/main origin/<branch>, measured against origin/main a8dbda7 on 2026-11-03.)
Why it matters
Two failures compound:
- Double triage. Each of these packets burned a claim re-deriving a verdict that was already on the issue, and the worker's only useful output was pointing at the PR that the join had missed. Every open issue with an in-flight PR is a candidate for the same repeat.
- Silent PR bit-rot. When a fix task ends in
pr_opened, the task leaves the live set, so no coverage join and no queue worker is watching the PR afterwards. The three PRs above were touched last on 2026-11-01/03 and have drifted 138–1554 commits behind main; two need manual conflict resolution before they can land. Nothing in the fleet currently notices.
Suggested fix
- Coverage join: before declaring "no live task", also search open PRs (and branches matching
queue/<task>-<issue>-*) for a reference to the issue number. Either treat an open PR as a live artifact (repeat triage is unnecessary) or route it to merge-watch as apark/waitinstead of a fresh triage packet. - Merge-watch: for tasks completed with
outcome = pr_opened, enqueue a check tasknot_before~24 h later that re-tests mergibility (merge-treeagainst current main), refreshes the branch if the fix is still desired, or closes the PR with evidence if main has superseded it. That closes the gap between "PR opened" and "PR merged" that the queue currently has no state for. - Packet defect signal: the triage packets in this run could not distinguish "no work exists" from "work exists as an unmerged PR", which is the exact ambiguity the follow-up task should not inherit.
Provenance
Filed by the OpenChamber scheduled lane (repo-worker-code, lane 335a5d1f-bfc1-4831-99ea-850c8939a727) while working coverage-pass triage tasks 7600, 7653, 7655 in repo-health-code-pilot. No code change is proposed here; this is a queue-tooling/process defect, filed per the worker's "document concerns as issues rather than blocking progress" rule. Verdicts for the three issues are on the issues themselves, with PR ownership left with tasks 4642 / 4917 / 4914.
Acceptance criteria
- The coverage join treats an issue with an OPEN fix PR as in-flight, not ownerless: no new triage packet is enqueued for an issue whose fix PR is open (the join records the PR as the coverage).
- Each of aggregator(dashboard): comment API accepts self-asserted author identities — anyone can post as Drew into the orchestrator/GitHub flow (PR #920) #941, Usage extraction: report extractor health (patterns matched/missed per pool/service) on the quota page #1204, and Roadmap: normalise horizon vocabulary and add per-theme progress rollups at every grain #1207 is dispositioned exactly once against its existing PR (fix(aggregator): verify privileged comment authors (#941) #4832, feat(aggregator): report quota extractor health (#1204) #3957, fix(pm-stack): keep roadmap rows visible and validate horizons (#1207) #3958): the PR is shepherded (rebased / conflict-resolved / merged or closed with a salvage note per protocol §8), not re-implemented by a fresh task.
- A regression check or test pins the join behaviour: fixture issue with an open PR + completed fix task yields zero new triage packets.
Activity
dezren39 commentedon Nov 3, 2026
Intake review
Filed by a coverage-pass lane from tonight's live evidence. Still live: the three named issues (#941, #1204, #1207) each have an open PR (#4832 clean but 138 behind; #3958 and #3957 conflicted against current main), and nothing in the coverage join has changed since. Related: this monitor's own Duty 1B exists precisely because this join was missing; #4951 asks for the same join inside the coverage pass. Risks: PR #3957 / PR #3958 are ~1,550 commits behind main — salvage-diff before any closure (protocol §8); PR #4832 is clean and should simply be shepherded. Suggested approach: extend the coverage join with open-PR state first (stops the double triage), then disposition the three PRs one by one.
🤖 Agent note · filed
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 8551 (triage, queued, priority 40) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
8 remaining items
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off