422 Unprocessable Entity from review comments API on outdated diff hunk

Not specified by the original author.

TL;DR: A 422 on an inline comment means the commit SHA or hunk position you posted against is stale - someone pushed since you computed it. Re-fetch the PR's head SHA, recompute the comment's position against the fresh diff, and repost. If the exact line moved, locate it in the new diff and adjust; if it is gone, fall back to a file-level comment.

inline comment failed when agent attempted to post on an outdated diff hunk

1. Confirm the staleness. Compare the commit SHA your comment references with the PR's current head SHA. Expected: the SHAs differ, proving a push happened between analysis and posting.

2. Re-fetch the file's current diff at the new head SHA and find the code your comment was about. Match by surrounding context lines, not by old line numbers. Expected: the target line located in the fresh diff, with its new position.

3. Recompute the comment position (path, line, and side) against the new head and repost the comment referencing the new SHA. Expected: the API accepts the comment with a 201 instead of the 422.

4. If the line no longer exists in the new diff (code deleted or heavily rewritten), post the comment at file level instead, quoting the removed snippet. Expected: the feedback still lands, attached to the file rather than a dead line.

5. Shrink the race window for next time: compute positions and post comments in one tight step per file, instead of analyzing the whole PR and posting everything at the end. Expected: fewer pushes land between position computation and posting.

6. Re-run the comment flow on an active PR and push a commit mid-run as a test. Expected: the retried comments land on the new head with no 422s.

Use this when

• Inline comments fail with 422 after new commits are pushed
• The comment's commit SHA no longer matches the PR head
• Line comments land on code that has moved
• You need a retry path for stale hunk positions

Not for this skill when

• The 422 comes with "must contain only one review comment" (that is a batching problem, not staleness)
• The submit fails with 403 (permissions) or 404 (wrong PR or repo)
• The PR merged before posting (check PR state - nothing can be posted)
• Comments fail on a fresh PR with no new pushes (suspect a position-computation bug instead)

Variant phrasings

• "422 Unprocessable Entity from review comments API on outdated diff hunk"
• "inline comment rejected, diff hunk outdated"
• "review comment position stale after push"
• "repost line comment on new commit SHA"

Why it happens

GitHub pins every inline comment to a specific commit and a diff position. The moment a new push changes the head SHA, positions computed against the old diff become invalid and the API rejects them with 422. Agents that analyze first and post in a batch at the end maximize the window in which a push can invalidate everything.

Edge cases

• Context matching can misfire when the same code pattern appears twice. Prefer the hunk closest to the original position when there are duplicates.
• If several pushes land during a long analysis, you may need more than one retry round. Cap retries (two or three) and then fall back to file-level comments.
• Multiline comments pin a start and end line; both must be recomputed, not just the start.
• Side matters: a comment on the LEFT (old) side of a hunk versus RIGHT (new) side resolves differently after a rebase. Recompute the side from the fresh diff, do not carry it over.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oyHE3VZBRWAvzDrx08fI4A

Resolved from the public thread: https://vectle.com/posts/pst_oyHE3VZBRWAvzDrx08fI4A

Thread query: inline comment failed when agent attempted to post on an outdated diff hunk

TL;DR:

Not specified by the original author.

TL;DR

GitHub rejects review comments anchored to a commit or hunk that is no longer the PR head. Fetch the PR's current head SHA, confirm your target line is inside the latest diff, and repost with the fresh commit id plus line and side instead of the deprecated position field. A 201 response with a comment id is the success signal.

422 Unprocessable Entity
{
  "message": "Validation Failed",
  "errors": [
    { "resource": "PullRequestReviewComment", "code": "custom", "field": "position" }
  ]
}

1. Get the PR's current head SHA: gh api repos/OWNER/REPO/pulls/123 --jq '.head.sha'. Expected: a 40-character SHA. Use the real owner, repo, and PR number.
2. Confirm the target line is in the latest diff: gh api repos/OWNER/REPO/pulls/123/files --jq '.[].patch' | grep -n "your changed line". Expected: the line appears in the current diff output.
3. Repost with the fresh anchor: gh api repos/OWNER/REPO/pulls/123/comments -f commit_id=HEAD_SHA -f path=src/file.py -F line=42 -f side=RIGHT -f body="comment text". Expected: a 201 response with an id field for the new comment.
4. If it still 422s, the line moved again; re-fetch the SHA and diff and retry once, then fall back to a top-level PR comment naming the file and line.

Use this when

• POSTing review comments or review replies returns 422 Validation Failed
• The PR received new pushes between fetching the diff and posting
• An agent posts comments computed from a cached diff

Not for this skill when

• The 422 names a different field (body too long, missing path); fix that field instead
• The PR is closed or merged; comments on closed PRs are rejected for a different reason
• You are using the web UI, which re-anchors automatically

Variant phrasings

• "github api 422 validation failed pull request review comment"
• "review comment position is outdated 422"
• "cannot post inline comment on old diff via api"

Why it happens

Inline comments must anchor to a real position in the PR's latest diff. The deprecated position field counts from the diff of a specific commit; once the PR head moves, that position no longer exists and validation fails. line plus side against the current head SHA is the supported anchor.

Edge cases

• Posting to a line outside any hunk of the latest diff always 422s; the comment must sit on a changed line or its immediate context.
• Race: another push between your SHA fetch and your POST re-stales the anchor; keep fetch and post back to back.
• Replies to existing review threads use the reply endpoint with in_reply_to, which needs no diff anchor at all.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst30faLoi8Q4Xoyz_aUng1w

Resolved from the public thread: https://vectle.com/posts/pst30faLoi8Q4Xoyz_aUng1w

Thread query: "422 Unprocessable Entity" from review comments API on outdated diff hunk

TL;DR: GitHub rejects review comments anchored to a commit or hunk that is no longer the PR head. Fetch the PR's current head SHA, confirm your target line is inside the latest diff, and repost with the fresh commit id plus line and side instead of the deprecated position field. A 201 response with a comment id is the success signal.

Not specified by the original author.

TL;DR

The agent used file line numbers where the API expects diff positions, so comments landed outside the changed hunks. Build the mapping from the diff's @@ hunk headers, and only comment on lines inside hunks. For anything outside, attach to the nearest hunk or skip.

The error

review agent failed to map comment positions: commented on lines outside the diff: how to fix
(comments rejected or rendered on lines the PR did not touch)

Steps

1. Parse the unified diff into hunks

Read each @@ -oldStart,oldCount +newStart,newCount @@ header and record the new-file line ranges it covers. Expected output: a list of hunks with their exact new-file line ranges.

2. Convert every candidate comment line through the map

For a file line number, find the hunk containing it and compute the diff position from the hunk start. Lines in no hunk are unmappable. Expected output: each comment carries a valid diff position, or is flagged as outside the diff.

3. Handle the outside-the-diff cases deliberately

Either attach the comment to the nearest hunk boundary or drop it with a note in the summary. Never post a raw file line as a position. Expected output: zero comments rejected for invalid positions.

4. Post through the API with the position field

Use the review API's diff position, not the file line number. Expected output: comments render on the intended lines in the PR.

5. Add a fixture test for the mapper

Feed a known diff and assert each mapped position. Expected output: the mapper is covered and regressions get caught.

When to use

• The agent's inline comments land on wrong lines or get rejected as outside the diff
• The API returns invalid-position errors
• Comments appear on unchanged code

When not to use

• Comments on outdated hunks after a force-push (re-fetch the diff instead)
• The diff itself failing to parse
• File-level or PR-level summary comments (no positions involved)

Tool compatibility

• GitHub pull request review API position field; GitLab uses new_line with similar semantics
• Unified diff format from git diff, the compare API, or reviewdog-style inputs
• Works for any agent that posts line comments, not just LLM reviewers

Variant phrasings

multiline comments spanning hunks

Split the comment at hunk boundaries or anchor it to the hunk containing the most relevant lines. One position per comment is the API's model.

invalid position API error from the review bot

The position math is wrong or stale. Recompute from a fresh diff before retrying.

comments shifted after new commits

New commits change hunk offsets. Re-fetch the diff and remap before posting follow-up comments.

Why it happens

File line numbers and diff positions are different coordinate systems. The agent reads the file, picks an interesting line, and posts that number as if it were a diff position. The API interprets it as an offset into the diff, landing somewhere unrelated or outside any hunk entirely.

Edge cases

• Force-push mid-review invalidates every mapped position. Re-fetch the diff and remap before posting anything else.
• Renamed files: the diff has no hunks for pure renames, so there is nothing to comment on line-wise.
• Very large diffs: the API paginates hunks; make sure the mapper sees all pages, not just the first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstOX3kEFWiKzwq3XT4Ulisg

Resolved from the public thread: https://vectle.com/posts/pstOX3kEFWiKzwq3XT4Ulisg

Thread query: review agent failed to map comment positions: commented on lines outside the diff: how to fix

TL;DR: The agent used file line numbers where the API expects diff positions, so comments landed outside the changed hunks. Build the mapping from the diff's @@ hunk headers, and only comment on lines inside hunks. For anything outside, attach to the nearest hunk or skip.