granthi-review is a REQUIRED status check on main, and Gitea counts a required
context as satisfied only on 'success'. failOpen posted 'warning' with the
description 'review unavailable - not blocking', so it did precisely what it
promised not to do: it blocked, while announcing it would not.
Measured: shreai PR #209 sat unmergeable for six days on a claude-cli failure
from 2026-08-23, every other gate green.
The failure is also non-deterministic. The same commit a49573f66 produced
'Grade A (86/100) - pass' on one review and a fail-open minutes later with no
code change. A state that flips on identical input is infrastructure noise, not
a review signal, and must not decide whether code can merge.
The gate is not weakened: reviews that actually run still gate, and a real
'fail' verdict still fails. Only 'could not review' now passes, which is what
fail-open has always meant. The reason still rides in the description and the
error is still persisted to the reviews table.
Codex adversarial review of the fallback chain found 1 P1 + 3 P2:
- P1: head-only and incomplete per-commit fallbacks could present a SUBSET
diff as a full passing review. fetchDiff now returns {diff, partial, note};
review.js caps partial reviews at 'warn' (same contract as truncation) and
labels the status 'partial review (<reason>)'.
- getRepo default-branch lookup swallows only 404; auth/5xx propagate.
- per-commit reconstruction dedupes + validates shas (40-hex) and hard-caps
at 20 requests; capped/short coverage marks the result partial; the
all-sources-failed message is bounded to 1500 chars.
- gitea.js URL-encodes every webhook-supplied path segment (owner/repo/ref/
sha) — branch names with '/' or '#' can no longer distort request paths.
Tests: 61 pass (2 new: sha cap/dedupe, getRepo 401 propagation).
Co-Authored-By: Claude Fable 5 <[email protected]>
~23% of reviews were failing open with `diff fetch failed: gitea GET
/{owner}/{repo}/compare/{before}...{after}.diff -> 404`. Probing the live
forge (Gitea 1.27.1) showed the web compare route answers 404 for ALL refs
on private repos — it does not honor `Authorization: token` and resolves as
anonymous — while the API compare (JSON) and per-commit
/git/commits/{sha}.diff endpoints succeed for the exact same sha pairs.
It also 404s legitimately when `before` is unknown (force-push, rebase).
fetchDiff now walks a fallback chain instead of failing open on the first
404 (any non-404 error still propagates immediately):
PR job: pulls/{n}.diff -> git/commits/{head}.diff
range push: web compare {before}...{after}.diff
-> web compare {defaultBranch}...{after}.diff
-> API compare commit list (falls back to the webhook's
commitShas) -> concatenated per-commit git/commits/{sha}.diff,
stopping past maxDiffBytes so the existing truncation cap
(verdict capped at 'warn') kicks in
-> git/commits/{after}.diff alone
new branch: git/commits/{after}.diff (unchanged)
Only when every source is exhausted does the review fail open, and the log
line now lists every URL tried. Webhook jobs carry the repo default_branch
so the fallback needs no extra API call; getRepo() covers recovered jobs
persisted before this change.
Verified against the live forge for the exact failing pair from today's
service.log (Nirlabinc/shreai 481d8663...46696b50): the chain recovers a
full-range 8,993-byte diff via 2/2 per-commit diffs.
Co-Authored-By: Claude Fable 5 <[email protected]>
Claude