Repository navigation
dispatch: orphan spec-less issues — the tracking issue is created before enqueue, so a failed dispatch leaves an empty task (59 open do the thing placeholders) #4925
Description
Found while triaging #2915 (queue task 8000, coverage pass 2026-11-03).
Problem
pm-stack/dispatch/src/server.ts handleSessions creates the GitHub tracking issue in step 1, before the queue enqueue (step 2) and the launch (step 3):
- On an enqueue failure the handler returns
502 {error, issue_number}(server.ts:219-227) and never comments on or closes the issue it just created. The issue is left as a bare prompt with the footer promising "Queue task and OpenCode session ids follow in a comment below" — a promise that never comes true. Only the launch failure path (launch_failure.ts:46, which cancels the task and comments) and the success annotation path (launch_annotations.ts) write to the issue. parseSessionRequestputs no floor on spec quality, so a caller sending a generic prompt gets a real repo issue whose entire body is that prompt. Title istitleFromPrompt(prompt), hence a family of issues literally titleddo the thing.
Consequence in this repo: 59 open issues titled do the thing (gh issue list --state open --search '"do the thing" in:title'), created 2026-10-31 through 2026-11-03, several per day. Each one is picked up by the coverage join as "open issue with no live queue task", so it costs a triage lane per issue and produces no work — the exact waste #2915's intake review described ("enqueueing an unspecified task would waste a lane"), except the issue itself now gets enqueued by coverage.
Work
- No orphan issues. Either create the tracking issue after the successful enqueue (preferred: the issue then always has a task id to name), or on the enqueue-failure 502 path comment the failure on the created issue and close it as not planned. Never return an
issue_numberfor an issue left dangling with no task. - Minimum spec gate. Reject (400) a session request whose prompt is trivially short or whose
titlewould be derived from such a prompt — e.g. require an explicittitlewhenpromptis under a small length. Never derive a repo issue title from a placeholder prompt. - Cleanup. Close the open
do the thingplaceholders (bulk,state_reason: not_planned, one comment each pointing here) and clear their queue coverage noise; verify no live queue task references them before cancelling any. - Tests. Enqueue failure leaves no open issue (or leaves a closed, commented one); a short/generic prompt is rejected at validation; a normal dispatch still posts task/session ids on the issue.
Evidence
pm-stack/dispatch/src/server.ts:194-227— issue created beforerequireQueue().enqueue; the 502 path returns without a comment or close.pm-stack/dispatch/src/server.ts:197—const title = body.title ?? titleFromPrompt(body.prompt).pm-stack/dispatch/src/launch_failure.ts:46-93— the only failure path that annotates the issue.gh issue list --repo developing-today/code --state open --search '"do the thing" in:title'→ 59 open.- do the thing #2915 — triaged and closed as the specimen; its 2026-10-31 intake review already flagged it as unactionable.
Not in scope: the dispatch auth/directory gates (#2903) and the launch failure handler (#2901), both working.
Acceptance criteria
- On an enqueue failure, the dispatch handler does not leave an orphan: the just-created tracking issue is closed (or commented with the failure and labelled so coverage skips it) in the same request path that returns the 502.
parseSessionRequestenforces a minimum spec floor: a prompt that cannot name work (e.g. the literaldo the thingfamily) is rejected with a 4xx naming the missing spec, before any issue is created.- The 59 existing open
do the thingplaceholder issues are dispositioned in bulk (closed as orphans with a pointer here, or adopted with a real spec) — the open-issue search for that title returns zero unexplained placeholders. - A test covers the enqueue-failure path asserting no open orphan issue remains.
Metadata
Metadata
Assignees
Labels
pm-stack (Pad/Grist) in developing-today/codeMedium: expected under 1 day 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 pilotTriaged and routed (see agent note)Queue packet kind: verify, reproduce, and route this item
Activity
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up + progress
Progress — task 8043 (lane H, 2026-11-03)
Code fix: PR #4948 — spec gate in
parseSessionRequest(no explicit title + prompt < 40 chars → 400),handleEnqueueFailurecleanup (comment + close as not planned) wired into both endpoints' packet-validation and enqueue failure paths (create path only on/v1/tasks; attached issues are never closed), andGitHubClient.closeIssue. 121 targeted bun tests pass on the laptop; details and the one environment caveat are on the PR.Cleanup item — already owned, not duplicated here. When this task reached the bulk close, the placeholder set was shrinking in real time (16 → 11 open exact-title
do the thingissues within minutes): another worker is running the same cleanup as queue task 8030 for #4917 — e.g. #4859 was closed at 2026-11-03T14:09:26Z as NOT_PLANNED with the comment "pm-dispatch orphan tracking issue (#4917 cleanup, queue task 8030)". Closing the same issues from this task would race it and double-comment, so this task does not bulk-close.One exclusion flagged for the cleanup owner: #2912 (still open, exact title) is referenced by live claimed triage task 8003 (
repo-health:v1:triage:developing-today/code:issue:2912) — per this issue's own work item 3 it must not be closed until that task resolves. The remaining open exact-title placeholders at this check: #2912, #4923, #4924, #4926, #4927, #4928, #4929, #4930, #4931, #4937, #4938 (none of the others has a live queue task).Incidental end-to-end evidence: a laptop test run of the fixed handler created #4944 and the new cleanup closed it NOT_PLANNED automatically (noted on PR #4948).
🤖 Agent note · done
dezren39 commentedon Nov 3, 2026
Intake review
The fix PR already exists: PR #4948 (task 8043, opened after this issue was filed) implements the spec gate + enqueue-failure cleanup — so this issue is in-flight, not ownerless; this intake links it rather than re-routing. Still live until PR #4948 merges and the 59 placeholders are dispositioned — note the PR covers the code path; the bulk disposition of existing placeholders may need its own follow-up if the PR doesn't include it. Risks: bulk-closing 59 issues needs the orphan test applied per issue (created-by-dispatch + no task + no spec), not a title-only match. Suggested approach: land PR #4948, then run the disposition pass it enables.
🤖 Agent note · filed
2 remaining items
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; ENQUEUE FAILED at review — flagged for the next pass 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
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
do the thingplaceholders) #4925 handed off to the opencode execution lane; claimant launches the bound opencode sessiondo the thingplaceholders) #4925dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
do the thingplaceholders) #4925, dispatch orphan spec-less issues) is assigned to the opencode execution lane; handing off to the laptop opencode claimant.do the thingplaceholders) #4925dezren39 commentedon Nov 4, 2026
agent-note:v1
event: picked_up
task: 8633 (triage, repo-health-code-pilot; worker repo-worker-code; lane 9aca43b4-5439-4939-9f71-323f5d32521b)
state: Claimed for fresh issue and dispatch-path review at current main.
next: Verify whether issue #4925 is still open, already fixed, or superseded; inspect implementation and queue behavior before routing.
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: triaged
task: 8633 (repo-health-code-pilot; worker repo-worker-code; lane 9aca43b4-5439-4939-9f71-323f5d32521b)
state: Issue #4925 remains OPEN; no competing code work started.
verified: PR #4941 is MERGED and issue #4917 is CLOSED; its fresh note reports 66 body-verified orphan issues closed, leaving #2912 and #4925 as open title matches. #2912 is now CLOSED. The current open-title search returns #4925 itself, whose real issue title merely mentions the placeholder phrase. PR #4948 remains OPEN, Drew-authored, and explicitly fixes #4925 with the spec gate and enqueue-failure cleanup.
next: Keep #4925 open until PR #4948 is resolved; do not modify the Drew-owned PR. The historical “59 open placeholders” count in the issue title/body is stale and is superseded by the #4917 cleanup evidence.