fix(review): omit leftover interiors from applyable suggestion ranges - #992
fix(review): omit leftover interiors from applyable suggestion ranges#992seonghobae wants to merge 31 commits into
Conversation
When GitHub refuses inline review comments, the PR-level fallback now lists each sanitized current-head finding location instead of a generic sentence. Suggested diffs stay out of the body.
Rebuild the fallback from gh api stderr after a refused attach so the OpenCode overview keeps each trusted path:line next to the GitHub 422 phrase instead of a location-only list.
A single invalid path:line 422s the whole comments array. After that failure, split the payload and retry each comment so surviving hunks still attach; remaining failures keep the overview receipts.
The publisher moved that phrase out of the workflow YAML, so the exact-head path-policy harness failed looking in the old file.
When some one-at-a-time inline comments attach and others 422, the overview must list only the refused locations so attached hunks are not reported as failed.
Mixed one-at-a-time retries can fail for different reasons. Record path:line plus that comment's gh api error so the overview does not reuse one shared sentence for every refused hunk.
Unbounded one-at-a-time retry after a batch 422 can thrash GitHub, and mixed receipts listed only refused locations. Cap retries at 20, persist attached path:line beside refused ones, and record leftovers the cap left untried so the overview shows every outcome.
GitHub 422s review comments that sit outside every current-head @@ hunk. Filter the payload against git diff --unified=3 first, post only the on-hunk comments, and persist skipped path:line as overview receipts.
Authors could not one-click apply OpenCode inline repairs because the payload only posted ```diff fences. Convert + lines from those diffs into ```suggestion blocks on surviving RIGHT-side hunk comments.
A surviving suggested_diff that removes more than one current-head line still posted as a single-line comment, so Apply suggestion only replaced the first line. Set start_line, line, and start_side when the full span sits on the same hunk; leave off-hunk spans single-line to avoid 422.
Authors could see refused and skipped path:line after a 422, but not which surviving hunks shipped as one-click GitHub suggestions. Persist path:line or path:start-end for comments that carry a suggestion fence.
Overview receipts listed applyable path:start-end ranges, but authors could not tell leftover ```diff fences (cannot-provide / LEFT) from one-click GitHub suggestions. Persist those leftover path:line reasons in a separate overview section.
Leftover cannot-provide and LEFT fences now keep a bounded excerpt in overview receipts as a distinct non-applyable ```diff block so authors can copy the replacement by hand without treating it as a GitHub suggestion range.
When a leftover LEFT suggested-diff still has an extractable replacement and the same path has a current-head RIGHT hunk, move the comment onto that hunk so GitHub can apply it. Pure deletions and cannot-provide fences stay leftover manual-edit blocks.
When a leftover LEFT comment cannot stay on the same RIGHT line, attach it to the first RIGHT line of that @@ hunk instead of the first RIGHT line of the whole path. Multi-hunk files no longer land on an earlier hunk. Pure-deletion hunks stay leftover.
Overview applyable receipts now show path:right came from LEFT path:left when a leftover comment was remapped onto a RIGHT hunk. Local origin keys are stripped before the GitHub POST.
One-at-a-time retry after a batch 422 now copies start_line and start_side so a remapped leftover that spans a multi-line RIGHT hunk still posts as one GitHub suggestion.
Comments past the 20-comment 422 retry cap are not posted as GitHub suggestions. Deferred overview rows now keep path:start-end and the LEFT origin, and those ranges are removed from the applyable heading.
A cannot-provide or pure-deletion leftover past the 20-comment retry cap still shows the Manual-edit ```diff block and the deferred range/origin row. Those fences stay off the applyable suggestion list.
When leftover and deferred share a path:line, the leftover heading prints the deferred range/origin first, then the Manual-edit excerpt. Deferred leftovers also appear before leftovers that were already posted.
When leftover heading already prefixes a deferred range/origin for the same path:line, skip the duplicate cannot-provide/LEFT reason bullet so authors see one deferred line then the Manual-edit excerpt.
When a leftover line sits inside a deferred multi-line path:start-end, prefix the deferred range and keep the Manual-edit excerpt immediately after it instead of repeating path:line — reason.
When several leftover lines sit inside the same deferred path:start-end, prefix that range once and keep each Manual-edit excerpt under it.
When a leftover line sits inside a trusted deferred multi-line path:start-end but is not itself a trusted finding, _trusted_receipt_subset used to drop the Manual-edit excerpt. Keep that excerpt under the deferred range and still drop untrusted-path leftovers.
When leftover-diff-locations sits inside a trusted deferred path:start-end but that leftover line is not a trusted control finding, the overview CLI still keeps the Manual-edit excerpt under the deferred range.
GitHub cannot apply a suggestion on the deleted LEFT side, so leftover LEFT fences must stay off the applyable overview. Darwin hosts now mock the linux x86_64 trusted-uv runner for installer verification.
When a leftover cannot-provide or LEFT line sits inside path:start-end, drop that range from the applyable overview so authors see Manual-edit instead of a one-click apply for the same span.
|
Warning Review limit reached
Next review available in: 4 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@cwl-noema-review |
Leftover Manual-edit text is copied into the overview HTML comment. A leftover --> or HTML metacharacter could close that comment or inject markup. Strip those sequences before the excerpt is stored.
|
@cwl-noema-review exact current head |
A leftover cannot-provide at example.py:6 next to a suggestion spanning example.py:5-7 still became an applyable range at the source. The write path then listed a one-click apply beside leftover Manual-edit. Drop those interiors inside applyable_suggestion_ranges so applyable.txt and the overview cannot advertise the same span as applyable.
|
@cwl-noema-review exact current head |
Materialize a base Python lock only when every package line is an exact SHA-256 pin or a two-token relative -r/--requirement include of a candidate lock path. A lone --require-hashes directive, ./dotted paths, and -r other-hashes.txt no longer enter the trusted build context.
|
@cwl-noema-review exact current head |
|
@cwl-noema-review exact current head |
Reject leftover 422-fallback paths that contain -->, <!--, or a suggestion fence so a leftover cannot close the overview HTML comment or reopen an applyable GitHub suggestion block.
|
@cwl-noema-review exact current head |
Summary
A leftover cannot-provide or LEFT
path:lineinside a GitHub suggestion range still became applyable at the source.applyable.txtthen listed a one-click apply next to leftover Manual-edit for the same span.This increment drops leftover interiors inside
applyable_suggestion_ranges. Leftoverexample.py:6omits applyableexample.py:5-7and keeps a disjointexample.py:11. The leftover heading still shows the reason bullet and Manual-edit.Verification
example.py:6next to suggestionexample.py:5-7leaves applyableexample.py:11only;applyable.txthas noexample.py:5-7.coverage run -m pytest tests && coverage report --show-missingtwice at 100% (1025 passed,scripts/ci100% statement/branch), theninterrogate100%.@cwl-noema-review