fix(source-control): emit in_reply_to_id for threaded inline PR review replies - #1350
Conversation
…w replies fetch-all-pr-comments.sh never projected the GitHub REST field that marks an inline review comment as a threaded reply, so callers reading the script's output saw the key absent even for properly-threaded replies GraphQL confirmed were linked. Reproduced against live PR #563 data: the raw pulls/<pr>/comments response correctly carries in_reply_to_id — the script's jq mapping for the inline surface simply dropped it. Adds in_reply_to_id to all three surfaces (sourced from the raw field for inline comments; null for general/review, which have no reply-parent concept). Additive schema change, no breaking impact on existing consumers. Closes #587 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 1m 21s —— View job PR Review
SummaryThis is a clean, narrow fix. The root cause is accurately diagnosed, the jq change is correct, and the regression tests are properly constructed. One minor unexplained noise change worth noting.
|
|
Claude finished @kyle-sexton's task in 1m 20s —— View job Security Review
No security issues found. The change is purely additive: it threads the
The only substantive change is:
The value of The pre-existing
The new test stubs are written to a
Version bump and changelog prose — no code, no security impact. |
…ge() range Two follow-ups from review of 431a27e: - The in_reply_to_id docstring asserted "the id of the inline comment this one replies to" and steered callers away from the REST cross-check that reference/review-discipline.md and skills/pull-request/SKILL.md already prescribe. Live PR #563 data shows GitHub sets the field to the THREAD-OPENING comment id, not the immediately-preceding reply (every parent referenced in that thread set was itself a root comment) — the docstring now states that correctly and stops contradicting the two canonical reference docs, which were never wrong. - usage()'s `sed -n '2,18p'` range was written against the old (pre-fix) header length. Adding the in_reply_to_id block pushed the Usage/Env overrides sections past line 18 without updating the range, so --help silently truncated before showing them. Range corrected to 2,30p and verified against actual --help output. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 3m 1s —— View job PR Review
What changed since the last reviewThe latest commit (
|
|
Claude finished @kyle-sexton's task in 1m 37s —— View job Security Review
No security issues found. The diff introduces four changes; each is assessed below.
|
Compose both sides. CHANGELOG: main's 0.26.4-0.26.8 entries stay, this branch's in_reply_to_id entry moves to a new 0.26.9 section, manifest bumped to 0.26.9. fetch-all-pr-comments.sh: both sides extended the header comment (this branch +12 lines, main's PYTHONUTF8 block +9), so usage() prints through line 39 — the line before "# Exit codes:", which is the range the script has always used. All 23 script checks pass, including both sides' --help assertions.
|
Claude finished @kyle-sexton's task in 2m 14s —— View job PR Review
What changed in the merge commit (
|
|
Claude finished @kyle-sexton's task in 1m 11s —— View job Security Review
No security issues found. The diff touches four files; each is assessed below against the changed lines only.
|
…ts header The comment-hygiene gate flags a tracker/PR reference in a code comment, and the repo's convention reserves back-references for TODO(#issue). The empirical claim is what matters, not which pull request it was observed on, so the sentence now cites live review-thread data without naming one.
|
Claude finished @kyle-sexton's task in 1m 17s —— View job PR Review
What changed in
|
|
Claude finished @kyle-sexton's task in 1m 45s —— View job Security Review
No security issues found. The PR adds four changes; each is assessed below.
|
# Conflicts: # plugins/source-control/.claude-plugin/plugin.json # plugins/source-control/CHANGELOG.md
|
Claude encountered an error after 2s —— View job I'll analyze this and get back to you. |
|
Claude encountered an error after 2s —— View job I'll analyze this and get back to you. |
|
Warning Automated review did not complete — this is an infrastructure failure, not a review verdict. Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."
Re-running the job, or pushing a new commit, will retry the review. |
|
Warning Automated security review did not complete — this is an infrastructure failure, not a review verdict. Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."
Re-running the job, or pushing a new commit, will retry the review. |
Summary
fetch-all-pr-comments.shnever projected the GitHub RESTin_reply_to_idfield into its unified output schema for inline review comments, so any caller reading the script's own output saw the key absent (surfacing asNone/nulldownstream) even for comments that GraphQL confirmed were properly threaded replies.gh api repos/melodic-software/claude-code-plugins/pulls/563/commentscorrectly carriesin_reply_to_idon reply comments (e.g. id3611618764→in_reply_to_id: 3611576636) — the script'sjqmapping for the inline surface simply dropped the field on the way out.in_reply_to_id: .in_reply_to_idto the inline mapping, andin_reply_to_id: nullto the general/review mappings (those surfaces have no reply-parent concept). Purely additive to the schema — no existing consumer (babysit_findings.py,babysit_classify.py) reads this key today, so nothing breaks.source-controlto 0.26.3 with a matching CHANGELOG entry.Closes #587
Test plan
fetch-all-pr-comments.test.sh: top-level inline comment →in_reply_to_id: null; threaded inline reply → true parent id; general/review comments →in_reply_to_id: nullbash plugins/source-control/scripts/fetch-all-pr-comments.test.sh— 21/21 passshellcheckclean on both modified scriptsRelated
N/A
🤖 Generated with Claude Code