Duplicate replies to PR issue-comments: webhook + worker both post

[FidoCanCode]

Observed

On rhencke/orly PR #55, the user posted one question (comment 4270855450 at 19:56:14Z). Fido posted two different replies to it:

• 4270857752 at 19:56:37Z — "Probably not a canonical one from id..."
• 4270859288 at 19:56:52Z — "Not an obvious drop-in one, no..."

Both top-level PR issue comments, same author (FidoCanCode), answering the same question with independently-generated text.

Why this slipped past the #566 fix

#566 / #662 closed the TOCTOU on duplicate review-thread comment replies via the _replied_comments claimed set filtered in handle_threads. Issue comments on a PR take a different path:

• Webhook side: comment_issue() posts a new top-level PR comment, cleanly.
• Worker side: the rescope creates a thread task whose thread.comment_type is "issues". Fido runs sub/task.md's "PR comment" branch, which calls gh api .../pulls/{pr}/comments -F in_reply_to=.... That endpoint is for inline review comments — posting with an in_reply_to pointing at an issue-comment id 422s (we've seen PullRequestReviewComment: in_reply_to: invalid in the logs). Copilot then falls back to gh api .../issues/{n}/comments and posts a second top-level.

Result: webhook's reply + worker's fallback reply = double post.

The _replied_comments claim system exists but isn't consulted on the worker's issue-comment path.

Fix

Two options, probably both:

1. Worker side — when a thread task has thread.comment_type == "issues", check whether the webhook already claimed/posted a reply for this comment_id. If yes, mark the task complete without invoking the provider. Same logic as the review-thread filter but driven off the issue-comment claimed set.
2. Prompt side — sub/task.md's reply block is written for review-comment threads (uses in_reply_to). It has no correct path for issue comments. Either (a) make issue-comment thread tasks post via the in-reply semantic GitHub supports (quote/attribute the parent comment text, top-level reply on the issue) and rely on the claim filter to prevent dupes, or (b) drop issue-comment thread tasks entirely from worker scope — the webhook's reply is always sufficient, so turn issue-comment thread creation into a no-op or at most a rescope signal.

Option (b) is simpler and matches what actually happened cleanly on #55: the webhook reply was fine; the worker reply was pure duplication.

Why this matters

We just fixed one class of duplicate reply (#566). This is the same class on a parallel path. Reviewers see two conflicting / slightly-different answers from fido and don't know which to trust.

Sub-issue of

Bugs work order: #41 (may be at 100-cap; file standalone under v1 if link fails).

[FidoCanCode]

Fresh repro on rhencke/orly#59, showing the pattern is alive after PR #670 merged:

Reviewer (rhencke) posted one comment 4271391131. Fido then posted four replies within 88 seconds, all top-level issue comments, all in_reply_to_id: null:

id	at	body preview
4271392363	+16s	"Good catch. I'm going to verify the deployed map's cache behavior…" (triage ack)
4271395693	+56s	"Good catch. I'm folding cache verification into the deployed Pages checks…" (triage ack, slightly re-worded)
4271396052	+60s	"Updated the queued task to match this note: …" (task-created notice)
4271398420	+88s	"Updated the queued task from your note here: …" (task-created notice, re-worded)

So two separate duplication paths stacked:

1. Triage ack — two webhook handlers or two reply passes both ran triage + posted an acknowledgement. Same class of bug as the one in the issue body.
2. Task-created notice — rescope (_notify_thread_change) posted the "Updated the queued task" message twice. Possibly because the rescope ran twice (fanout from two webhooks for the same comment), or because the notification path itself doesn't dedupe.

Both shapes here are pure top-level /issues/{n}/comments posts — no threaded review-comment replies. So the claim system gap in this issue covers both cases.

Also reinforces the sibling bug #580 — "pointless 'task queued' reply posted to review thread" — here it's not just pointless, it's duplicated.

[FidoCanCode]

Picking up this one! Time to chase down those duplicate replies — same bug family as #672, different path. 🐕