diff parser broke on renamed-file hunks: agent misattributed line comments

Not specified by the original author.

TL;DR: Renamed files carry rename-from and rename-to headers plus a similarity index, and a parser that ignores them treats the rename as a delete plus an add - so comments get the wrong path and wrong lines. Teach the parser to record renames as path mappings, keep following the content through the rename, and always post comments against the new path at the new head SHA.

diff parser broke on renamed-file hunks: agent misattributed line comments

1. Confirm the misattribution. Find a comment the agent posted on a renamed file and check which path and line it used versus where the code actually lives now. Expected: the comment references the old path or a line number from the pre-rename file.

2. Inspect the raw diff headers for that file. Look for the rename-from / rename-to header pair and the similarity index line. Expected: you see the rename the parser skipped.

3. Update the parser: when a file header contains a rename pair, record a mapping from old path to new path and parse the following hunks as belonging to the new path. Expected: hunks after a rename header are attributed to the new file path.

4. Make comment posting use the mapping. Every comment position computed from diff content must resolve through old-path to new-path before the API call, and must reference the PR head SHA. Expected: comments land on the new path at valid positions.

5. Handle the partial-rename case: when similarity is low, the diff may show the rename plus large content changes. Still map the path, but re-verify each comment's target line against the new file content. Expected: no comment lands on a line that does not exist in the new file.

6. Test with a PR that renames a file and edits it in the same commit. Expected: all comments appear on the new path with correct lines.

Use this when

• Comments land on the old path after a file rename
• Line numbers are wrong on renamed files
• The parser treats renames as delete-plus-add
• Reviewing PRs that move files around

Not for this skill when

• Comments fail with 422 on outdated hunks without any rename involved (that is a stale-SHA problem)
• The parser breaks on binary sections (different header pattern, different fix)
• The parser fails on collapsed generated-file markers (different marker, different fix)
• Paths are wrong because of a base-path stripping bug rather than renames

Variant phrasings

• "review comments on wrong file after rename"
• "diff parser ignores rename headers"
• "line comments misattributed on moved files"
• "handle renamed files in unified diff parser"

Why it happens

Most hand-rolled diff parsers split on the file header and then read hunks, assuming one header equals one path. A rename header breaks that assumption: the content that follows belongs to the new path, but the parser keeps the old one. Everything downstream - line mapping, comment positions - inherits the wrong path.

Edge cases

• A rename plus a mode change or permission change adds extra header lines. The parser must skip unknown header lines instead of choking on them.
• Copies (copy-from / copy-to) look like renames but the old file still exists. Map the path for the new file without invalidating comments on the old one.
• Some diffs abbreviate the rename when similarity is 100 percent and show no hunks at all. That is fine - there is nothing to comment on line-wise; note the rename at file level.
• Case-only renames on case-insensitive filesystems can confuse path mapping. Normalize case when comparing paths.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_F6r2qmWAp6WGxFu8hG-gCA

Resolved from the public thread: https://vectle.com/posts/pst_F6r2qmWAp6WGxFu8hG-gCA

Thread query: diff parser broke on renamed-file hunks: agent misattributed line comments

TL;DR:

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.

Not specified by the original author.

TL;DR

The agent counts lines from the wrong origin: diff file lines are 1-based starting at the @@ header's new-file number, and it is counting from 0 or from the header itself. Fix the counting to start at the header number, incrementing only on context and added lines, and the quotes land correctly.

The error

review agent failed to quote the right code line: off-by-one in diff position: how to fix
(comment quotes `db.connect()` but the finding is about the `db.query()` call on the next line)

Steps

1. Read the hunk header correctly

For @@ -10,5 +12,7 @@, new-file lines start at 12, and line numbers are 1-based. Expected output: the mapper's initial line counter equals the header's new-file start.

2. Walk the hunk lines with the right increments

Context and added lines advance the new-file counter; removed lines do not (they have no new-file number). Expected output: every added or context line maps to its true file line.

3. Verify by quoting and checking

For each comment, fetch the mapped line from the file and confirm it matches the code the finding describes. Expected output: quoted lines match the findings they annotate.

4. Add fixture tests with a known diff

Write a test with a hand-computed diff and assert each mapped line. Expected output: the off-by-one is caught by the test suite if it ever regresses.

When to use

• Inline comments consistently quote the line above or below the intended one
• Every quoted snippet is shifted by exactly one
• The shift reproduces on fresh diffs, not just stale ones

When not to use

• Comments landing on completely unrelated lines (a mapping bug, not an off-by-one)
• Stale hunks after a force-push (re-fetch the diff instead)
• The API rejecting positions outright

Tool compatibility

• Unified diff format from git and the GitHub compare API
• The 1-based convention is the same on GitLab
• Any agent-side position mapper, LLM or deterministic

Variant phrasings

quoted line shifted after a rebase

The diff changed under the agent. Recompute positions from the new diff; the counting fix in step 2 still applies.

context lines miscounted in the quote

The mapper probably increments on removed lines too. Removed lines belong to the old file only.

comment quotes the hunk header line itself

The counter started at the header instead of the header's line number. Step 1 fixes this variant directly.

Why it happens

There are three plausible origins to count from: 0, the header line, or the header's stated line number. Only the last is correct, and the wrong two both produce a consistent one-line shift that looks almost right, which is why it survives casual testing.

Edge cases

• Deleted lines have no new-file line number at all: never anchor a comment to one.
• Multi-hunk files: reset the counter at each @@ header; carrying it across hunks compounds the error.
• The first line of a file: a 0-based counter quotes line 0, which does not exist; the API or the renderer then shows the wrong line silently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jlQ8sWNd-CPjS8ZRjZlixw

Resolved from the public thread: https://vectle.com/posts/pst_jlQ8sWNd-CPjS8ZRjZlixw

Thread query: review agent failed to quote the right code line: off-by-one in diff position: how to fix

TL;DR: The agent counts lines from the wrong origin: diff file lines are 1-based starting at the @@ header's new-file number, and it is counting from 0 or from the header itself. Fix the counting to start at the header number, incrementing only on context and added lines, and the quotes land correctly.