fix: handle @docker-agent mentions in inline PR review comments (pull_request_review_comment)

[docker-agent]

Problem

When someone @docker-agent mentions in an inline PR review comment (a pull_request_review_comment event), the reply-to-mention job was always silently skipped and the 👀 reaction call would use the wrong GitHub API endpoint.

Three bugs combined to produce this:

1. Workflow if: condition — the reply-to-mention job only matched issue_comment events; pull_request_review_comment events were never routed to it.

2. parseEventContext() payload mismatch — src/mention-reply/index.ts always read the PR number from raw.issue.number, which does not exist in pull_request_review_comment payloads (the PR lives at raw.pull_request.number there).

3. Wrong reactions API — src/add-reaction/index.ts always called createForIssueComment, which 404s on review comments; createForPullRequestReviewComment is needed instead.

Changes

.github/workflows/review-pr.yml

• reply-to-mention job if: — adds an OR branch for pull_request_review_comment events. No github.event.issue.pull_request guard is needed (review comments are always on PRs).
• Add completion reaction step — routes to the correct gh api endpoint (pulls/comments vs issues/comments) depending on EVENT_NAME.

src/add-reaction/index.ts

• Exports a new CommentType = 'issue' | 'pull_request_review' type.
• Adds an optional commentType parameter (default 'issue') to addReaction().
• When 'pull_request_review', calls octokit.rest.reactions.createForPullRequestReviewComment instead of createForIssueComment.

src/mention-reply/index.ts

• Adds a commentType: CommentType field to EventContext.
• parseEventContext() now checks GITHUB_EVENT_NAME; for pull_request_review_comment it reads prNumber from raw.pull_request.number and sets isPrComment = true and commentType = 'pull_request_review'.
• The addReaction call passes ctx.commentType so the correct API endpoint is used.

Tests

• src/add-reaction/__tests__/add-reaction.test.ts — adds beforeEach mock reset; covers the new commentType parameter for both 'issue' and 'pull_request_review'.
• src/mention-reply/__tests__/mention-reply.test.ts — adds makePrReviewCommentEvent fixture and new describe blocks covering parseEventContext, runGuards, and run() for pull_request_review_comment events (guard paths, happy path, non-member path, correct reaction commentType). Test count goes from 25 to 36.

Testing

pnpm build    # clean
pnpm test     # 120/120 passed
biome ci .    # no errors
tsc --noEmit  # no errors
actionlint    # no errors

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

The core fix is correct — comment events are now properly routed, the right GitHub API endpoints are used for reactions, and PR numbers are read from the correct payload field. Two issues in the workflow if: conditions were found.

[docker-agent]

[MEDIUM] Double bot response when a user replies to a review comment and mentions @docker-agent

When a user replies to an existing inline review comment and includes @docker-agent in that reply, both reply-to-feedback and the newly-added reply-to-mention branch fire simultaneously on the same event:

• reply-to-feedback triggers because: pull_request_review_comment + github.event.comment.in_reply_to_id is set (it's a reply) + user is not docker-agent
• reply-to-mention triggers because: pull_request_review_comment + contains(@docker-agent) + user is not docker-agent

Neither condition checks for the other. The result is two concurrent agent runs posting separate responses to the same comment — a confusing double-response the user did not ask for.

This overlap was not possible before this PR because reply-to-mention only handled issue_comment events. The reply-to-feedback job (line 364) would need a !contains(github.event.comment.body, '@docker-agent') guard, or reply-to-mention would need !github.event.comment.in_reply_to_id to break the ambiguity.

[docker-agent]

Fixed in the latest commit. Added !github.event.comment.in_reply_to_id as the first guard in the pull_request_review_comment branch, so reply-to-mention only fires on fresh top-level inline comments. Replies to existing threads — including those containing @docker-agent — fall through exclusively to reply-to-feedback, which has the full thread context. No more double-response.

[docker-agent]

[LOW] Missing /review guard in the pull_request_review_comment branch of reply-to-mention

The issue_comment branch guards against /review-prefixed comments (line 705: !startsWith(github.event.comment.body, '/review')), but the new pull_request_review_comment branch does not:

(github.event_name == 'pull_request_review_comment' &&
contains(github.event.comment.body, '@docker-agent') &&
# ← !startsWith(..., '/review') is missing here
github.event.comment.user.login != 'docker-agent' &&
github.event.comment.user.type != 'Bot')

If someone writes /review @docker-agent as an inline PR review comment, the reply-to-mention job will spin up unnecessarily. The TypeScript runGuards() does catch this and exits cleanly (so no incorrect output is produced), but runner minutes are wasted on every such event.

Suggested fix: add !startsWith(github.event.comment.body, '/review') && after the contains(...) check in this branch.

[docker-agent]

Fixed in the same commit. Added !startsWith(github.event.comment.body, '/review') to the pull_request_review_comment branch, immediately after the @docker-agent mention check — matching the guard that already existed in the issue_comment branch.

[derekmisler]

/review

[docker-agent]

Assessment: 🟢 APPROVE

The three bug fixes are correctly implemented:

1. Workflow if: condition — reply-to-mention job now correctly matches both issue_comment and pull_request_review_comment events, with the appropriate !github.event.comment.in_reply_to_id guard to avoid double-responding on thread replies.

2. parseEventContext() payload mismatch — pull_request_review_comment events now correctly read prNumber from raw.pull_request.number and set commentType = 'pull_request_review'.

3. Wrong reactions API — addReaction() correctly routes to createForPullRequestReviewComment vs createForIssueComment based on commentType.

4. Completion reaction routing — The Add completion reaction shell block correctly dispatches to pulls/comments vs issues/comments endpoints based on EVENT_NAME, and the exit 0 guard on non-success outcomes intentionally drops the old confused reaction (per the earlier bebd4e8 commit).

5. Tests — New test fixtures and describe blocks cover the pull_request_review_comment happy path, guard paths (in-reply-to filter, bot/self-reply), non-member path, and correct commentType propagation. Test count grows from 25 → 36.

No bugs found in the changed code.