Repository navigation
fix(pm-dispatch): POST /v1/tasks issue_number attach never verifies the issue exists, is open, or is an issue #3007
Description
fix(pm-dispatch): POST /v1/tasks issue_number attach never verifies the issue exists, is open, or is an issue
Finding
PR #2676 (commit dbab526) added the issue_number attach flow to POST /v1/tasks: instead of creating an issue, the task attaches to an existing one. The attach target is never verified. parseIssueNumber (pm-stack/dispatch/src/validate.ts) checks only that the value is a positive integer, and handleTasks (pm-stack/dispatch/src/server.ts:280-284 on current main bfbd1454f1) constructs the issue reference purely from the request:
issue = {
number: body.issueNumber,
url: `https://github.com/${body.repo}/issues/${body.issueNumber}`,
};There is no GitHub lookup anywhere on this path — GitHubClient (pm-stack/dispatch/src/github.ts) has no get-issue method at all (only createIssue, addLabels, comment, ensureLabel).
Why it matters
- Nonexistent number: the task still enqueues (anchored to the canonical dedupe key for the phantom issue,
server.ts:292-295), the response returns HTTP 201 withissue_numberand anissue_urlthat 404s, and the only signal is twowarningsentries after the comment/label calls fail. A caller typo silently mis-tracks the work. - Pull request number: the GitHub issues API treats PRs as issues, so the agent-note comment and the
queue/queued+source/dispatchlabels succeed — on a PR, which then looks like queued fleet work. - Closed issue: comment and labels also succeed, so a closed (possibly completed) issue is re-labelled
queue/queuedand noted as newly queued work.
Verified still present on current main bfbd1454f10ab1c6e7f9e8bb173feee4b58d4223 (server.ts:280-284, same construction; no lookup added since #2676 merged 2026-10-30).
Distinct from #2677
#2677 covers the attach flow returning a pre-existing dedupe-collided task as if new. This issue is the missing existence/state verification of the attach target itself; neither fix substitutes for the other.
Acceptance criteria
- Before enqueueing, the attach path verifies via the GitHub App (or the
ghfallback) thatissue_numberinrepoexists, is an issue (not a pull request), and is open; a failed check returns a 4xx naming the problem and enqueues nothing. - For repos where the GitHub App is not installed (attach currently warn-skipped), the response makes the unverified state explicit rather than returning the same
issue_urlshape as a verified attach. - Tests (stubbed GitHub client) cover: nonexistent number, PR number, closed issue, and the happy path of an open issue.
Activity
dezren39 commentedon Oct 31, 2026
🤖 Agent note · filed
issue_numberattach flow never verifies the target issue exists, is open, or is an issue (not a PR) before enqueueing and returning 201 with an issue_url.16 remaining items
dezren39 commentedon Oct 31, 2026
🤖 Agent note · picked up
queue/4532-3007-attach-verify(pending)fix(pm-dispatch): match HTTP 404 status only in gh lookup errors (#3007…
dezren39 commentedon Oct 31, 2026
🤖 Agent note · parked
attach_verified: false). Codex P2 (404 regex could match the issue number in the echoed gh path) fixed in 291030a and replied on its thread. Laptop tests: new suite 11/11, full suite 66/66. Coordination with PR fix(pm-dispatch): detect pre-existing enqueue row — attach dispatch must not silently vanish (#2677) #3143 (pm-dispatch(tasks): a second dispatch to an already-tasked issue silently vanishes — enqueue returns the old task and dispatch reports it as the new queued task #2677): trial merge of the two branches verified clean after relocating the helpers; correction to my pickup note — the first trial merge DID conflict at the shared insertion anchor, the relocation fixed it. Parked 20m for CI (only CodeRabbit check appeared in the 5-min poll; no Actions runs yet).queue/4532-3007-attach-verify· laptop worktree~/git/fleet/4532-3007-attach-verifyMerge pull request #3149 from developing-today/queue/4532-3007-attach…
dezren39 commentedon Oct 31, 2026
Fixed and merged via PR #3149 (merge commit c92aa62).
The attach path now verifies
issue_numberbefore enqueueing: the target must exist, be an issue (not a PR), and be open; invalid targets return 4xx and enqueue nothing; GitHub lookup failures are distinguishable (5xx/retryable); app-not-installed repos return an explicitly unverified attach state. The one Codex P2 (matching a bare404digit scan in gh error text) was fixed in 291030a and replied to on its thread; Codex's fresh round on 291030a completed with no findings. Targeted tests on the laptop at the merged head:bun testin pm-stack/dispatch — 68 pass / 0 fail (215 expect calls), including the new stubbed-GitHub attach tests (nonexistent, PR number, closed issue, open-issue happy path). No substantive GitHub Actions workflow triggers for this path (only the jules-daily workflows that fail on every push, including main — unrelated infra).Queue task 4532 completed as fixed_merged by lane C.