fix(pm-dispatch): wait:false launch failures leave the queue task queued and the issue unnoted

Finding

In pm-dispatch (pm-stack/dispatch), a failed session launch on the wait:false path is not cleaned up: the queue task is left queued and the tracking issue is never noted. Only the wait:true path cancels the task and notes the issue — the exact behaviour PR #2650's description promises for failed launches generally ("a failed launch cancels the task and notes the issue").

Evidence

PR feat(pm-stack): pm-dispatch — launch/track OpenCode sessions from GitHub Actions #2650 (commit 19f12cb2e2, MERGED) introduced the service. Its body states: "wait:false answers 202 after the enqueue and finishes the launch asynchronously; a failed launch cancels the task and notes the issue."
Verified on current main (c4fb599617166d4c705eabeb34442ca179ecb9a6), pm-stack/dispatch/src/server.ts:222-240: the async catch only does patchTask(task.id, { last_error: "dispatch launch failed: …" }). No cancelTask, no issue comment.
Contrast the same file's wait:true path (~line 246+), whose comment states the invariant the async path violates: "Never leave a queued/claimed task behind for a session that did not launch: cancel it and note the failure on the issue."

Why it matters

The task stays queued, so a queue worker can claim and execute the packet — while in the partial-failure case (launch got as far as createSession + sendPrompt and failed afterwards, e.g. at the claim PATCH) a live OpenCode session is also working the same prompt. That is the double-booking the immediate-claim design exists to prevent.
The caller received 202 {status: "launching"} and the tracking issue says nothing further; the failure exists only as last_error on a still-queued task row, indistinguishable from a normally-queued dispatch at a glance.
Follow-up PRs fix(pm-dispatch): unwrap the OpenCode v2 {data} response envelope #2652/fix(pm-dispatch): register the dispatch-opencode worker row before claiming #2655/feat(pm-dispatch): record the lane assignment after a launch claim #2658 fixed three other launch-path defects found by deploy smoke tests (envelope, worker FK, lane ledger); none touched this branch.

Acceptance criteria

The wait:false async failure path mirrors the wait:true one: cancelTask(task.id, …) is called and, when a tracking issue exists, a comment records that the launch failed and the task was cancelled.
A regression test (stubbed queue/opencode clients, as in the existing test/ suite) covers a wait:false launch failure and asserts the cancellation + issue note.
The README's description of wait:false failure behaviour matches the implementation.

Found by the pr-diff-review job reviewing PR #2650 (batch 2630–2658, 2026-10-30). Deduped: gh issue list --search 'pm-dispatch wait launch cancel' and 'wait:false dispatch' (open + all) returned nothing covering this.

🤖 Agent note · filed

Agent: pr-diff-review job
Session / ID: pr-diff-review cron run 2026-10-30 20:24 CDT (batch PR ci: main-only workflow triggers, cancel-in-progress everywhere #2630–feat(pm-dispatch): record the lane assignment after a launch claim #2658, developing-today/code)
Found via: filed this run
Task: PR feat(pm-stack): pm-dispatch — launch/track OpenCode sessions from GitHub Actions #2650's wait:false async launch-failure path only sets last_error on the task; unlike the wait:true path it never cancels the task or notes the tracking issue, contradicting the PR body's promise and risking a queue worker double-booking work a partially-launched session is already doing.
Expectation: effort s — triage packet enqueued (repo-health-code-pilot); the queue worker verifies against current main before any fix
Links: fix(pm-dispatch): wait:false launch failures leave the queue task queued and the issue unnoted #2901

🤖 Agent note · triaged — CONFIRMED

Agent: queue worker (repo-worker-code), lane C shift
Session / ID: queue triage task 4128
Found via: queue claim (packet from pr-diff-review of PR feat(pm-stack): pm-dispatch — launch/track OpenCode sessions from GitHub Actions #2650)
Task: verify the wait:false launch-failure finding and route it
Verdict: CONFIRMED verbatim on current main (c4fb59961, read fresh 2026-10-31): in pm-stack/dispatch/src/server.ts the wait:false async catch (~L222-240) does only patchTask(task.id, { last_error: "dispatch launch failed: …" }) — no cancelTask, no issue comment. The wait:true path in the same handler (~L246+) states the invariant ("Never leave a queued/claimed task behind for a session that did not launch: cancel it and note the failure on the issue") and implements cancel + comment + 502.
README nuance for the fix: README L62-71 currently documents the wait:false failure as last_error-only and scopes the cancellation promise to "(wait: true)" — after the fix both sentences must change, not just the code.
Test seam note: queue/github/opencode clients are module-level singletons in server.ts (const github = new GitHubClient(...), requireQueue()); the existing test/ suite (auth/config/packet/validate) has no server-level test, so the regression test needs a small stub seam — keep it minimal.
Routed: fix enqueued as queue task 4135 (small_fix, dedupe repo-health:v1:fix:developing-today/code:issue:2901) with the three acceptance criteria from this issue.

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane C shift
Session / ID: queue triage task 4128 → fix task 4135
Expectation: triage complete (CONFIRMED, note above). This issue returns to queue/queued for the fix task 4135, which carries the acceptance criteria; the fixing worker re-syncs labels on claim.

🤖 Agent note · picked up

Agent: queue worker (repo-worker-code), Lane E shift
Session / ID: queue task 4135
Found via: queue claim
Task: Fix fix(pm-dispatch): wait:false launch failures leave the queue task queued and the issue unnoted #2901: pm-dispatch wait:false launch failure must cancel the task and note the tracking issue, mirroring wait:true; regression test + README update.
Expectation: effort class s; done = PR opened with the fix + tests, task parked/completed per CI.
Links: triage task 4128 (CONFIRMED on current main)

🤖 Agent note · filed (cross-reference added on a correction pass)

Agent: pr-diff-review job
Session / ID: pr-diff-review cron run 2026-10-30 20:24 CDT — correction pass
Found via: filed this run
Task: Recording why this issue is NOT a duplicate of the pm-dispatch launch-pipeline items filed earlier today.
Links: Related: pm-dispatch(sessions): a GitHub comment/label failure after the claim PATCH cancels a live session's queue task — the launched session keeps running untracked #2660, design(pm-dispatch): launch pipeline, staged — validate the whole request at the boundary, one commit point, nothing after it can fail the launch #2668

Relation to the existing launch-pipeline set: #2660 covers the opposite failure on the synchronous path — a comment/label failure after the claim PATCH cancelling a live session's task. #2668 (design epic) scopes its phases to #2664/#2665 (boundary), #2660 (commit point), and #2663 (retryable init). This issue is a fifth, distinct defect not in that set: on the wait:false path, a launch failure before the claim leaves the task queued and claimable, with no cancellation and no note on the tracking issue. If the #2668 staged redesign is implemented, its failure-semantics table should cover this async branch too; until then this issue tracks it directly. (Two sibling issues from this same run, #2902/#2903, WERE duplicates of #2663/#2664 and have been closed as such.)

fix(pm-dispatch): post-launch issue annotations are best-effort (#2901,…

fix(pm-dispatch): wait:false launch failure cancels the task and note…

🤖 Agent note · done

Agent: queue worker (repo-worker-code), Lane E shift
Session / ID: queue task 4135
Found via: queue claim
Task: PR fix(pm-dispatch): wait:false launch failure cancels the task and notes the issue (#2901) #2911 merged (2ef9dd2): wait:false launch failures now cancel the task and note the tracking issue, mirroring wait:true — both paths share handleLaunchFailure (src/launch_failure.ts) with stubbed-client regression tests; README updated. Codex round-1 P2 (post-launch annotations rejecting a running launch) fixed in b2ae5be by making launchSession's issue comment/labels best-effort; Codex round-2 clean.
Expectation: done = PR merged. Laptop bun suite 42/42 PASS; no CI workflow covers pm-stack/dispatch on PRs, so the laptop suite + Codex review are the verification of record.
Links: PR fix(pm-dispatch): wait:false launch failure cancels the task and notes the issue (#2901) #2911

Navigation Menu

Repository navigation

fix(pm-dispatch): wait:false launch failures leave the queue task queued and the issue unnoted #2901

Finding

Evidence

Why it matters

Acceptance criteria

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

fix(pm-dispatch): wait:false launch failures leave the queue task queued and the issue unnoted #2901

Description

Finding

Evidence

Why it matters

Acceptance criteria

Activity

dezren39 commented on Oct 31, 2026

dezren39 commented on Oct 31, 2026

3 remaining items

dezren39 commented on Oct 31, 2026

dezren39 commented on Oct 31, 2026

dezren39 commented on Oct 31, 2026

dezren39 commented on Oct 31, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions