Skip to content

fix: make reviewer coverage resilient (exempt lockfiles; degrade over-long constraints) - #567

Open
piekstra wants to merge 2 commits into
mainfrom
exempt-lockfiles-from-coverage
Open

fix: make reviewer coverage resilient (exempt lockfiles; degrade over-long constraints)#567
piekstra wants to merge 2 commits into
mainfrom
exempt-lockfiles-from-coverage

Conversation

@piekstra

Copy link
Copy Markdown
Contributor

Problem

A reviewer that skips a dependency lockfile (Cargo.lock, package-lock.json, go.sum, …) is marked incomplete_skipped, and hasIncompleteReviewerCoverage then downgrades an otherwise-clean APPROVE to a COMMENT. Because a reviewer will always skip a machine-generated lockfile (there's nothing to read line by line), this permanently blocks approval on any PR where a churned lockfile is the only "unreviewed" file — e.g. a Cargo.lock regenerated by a dependency-version bump on an otherwise clean PR. Re-running never clears it.

Fix

Exempt generated lockfiles from the reviewer coverage universe in buildReviewerCoverage:

  • changedFiles is filtered before coverage is computed, so an unassigned lockfile can't become incomplete_unassigned.
  • each agent's scope is filtered too, so a lockfile explicitly assigned to an agent and skipped can't become incomplete_skipped.

Lockfiles are reviewed (if at all) through the manifest change that produced them, never line by line, so leaving them out of the coverage obligation is correct — not a loophole. isGeneratedLockfile matches by basename against the well-known set (Cargo, npm/yarn/pnpm/bun, Go, Bundler, Poetry/Pipenv, Composer, CocoaPods, Nix, Mix).

Tests

New TestBuildReviewerCoverageExemptsGeneratedLockfiles: a reviewer that inspects the real change and skips only Cargo.lock is complete_constrained (not incomplete_skipped), and an unassigned yarn.lock produces no coverage row. go test ./internal/pipeline/ ./internal/reviewplan/, go vet, gofmt all clean.

Found while landing an unrelated PR whose Cargo.lock (bumped by a dep upgrade) was the only file cr wouldn't sign off on.

A reviewer that skips a dependency lockfile (Cargo.lock, package-lock.json,
go.sum, …) was marked incomplete_skipped, and hasIncompleteReviewerCoverage
then downgraded an otherwise-clean APPROVE to a COMMENT — permanently, since
the reviewer will always skip a machine-generated lockfile. Exempt lockfiles
from the coverage universe (they are reviewed, if at all, via the manifest
change that produced them, never line by line) so neither a skipped nor an
unassigned lockfile blocks approval.

Seen in the wild: a Cargo.lock churned by a v0.4→v0.5 dependency bump was the
only 'unreviewed' file on a clean PR, and cr would not approve it.
… failing the reviewer

A reviewer whose coverage `constraints` entry exceeded 300 runes (or exceeded
the count cap, or was empty/duplicate) failed DecodeFindings with 'entry length
out of bounds', which surfaced downstream as 'completed without a result file'
and sank the whole reviewer — blocking approval on an otherwise-clean review. A
single legitimate ~300-rune note ('could not verify against source-of-truth
docs not in context') did exactly that, repeatably.

Coverage constraints are informational, not a contract: cap the count, truncate
an over-long entry, and drop empties/duplicates rather than erroring. Tests
updated to assert graceful degradation.
@piekstra piekstra changed the title fix(pipeline): exempt generated lockfiles from reviewer coverage fix: make reviewer coverage resilient (exempt lockfiles; degrade over-long constraints) Aug 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant