claude-code-review: intermittent no-verdict crash where both attempts short-circuit, cleared by a manual re-run

[dem-extra1]

What's wrong

claude-code-review.yml intermittently fails with no review comment posted at all -- not a stub (gha#185), not a hallucinated verdict (gha#295), not a quota skip. Both the initial attempt and the built-in stub-retry short-circuit, and require-review then fails on result: failure with nothing on the thread to explain it.

The tell in the job log is that both Run Claude Code Review composite invocations complete in ~20 ms with Install Bun reporting skipped:

##[start-action display=Run Claude Code Review;id=__c3a340dc-....run]
##[start-action display=Install Bun;id=__c3a340dc-....run.setup-bun]
##[end-action id=...setup-bun;outcome=skipped;conclusion=skipped;duration_ms=0]
##[end-action id=__c3a340dc-....run;outcome=success;conclusion=success;duration_ms=17]

The "Resolve final review outcome" step then reports the generic branch: "Claude review did not complete successfully and was not eligible for a stub-review retry."

Why it matters

The two documented no-verdict modes both have handling: a stub triggers the gha#185 same-prompt retry, and a quota skip is detected and reported. This one defeats both -- the retry runs and short-circuits identically -- so an ARDI loop gets a red required check with no findings to address and no signal distinguishing "the reviewer broke" from "the PR is bad".

Frequency, and the workaround that reliably clears it

Observed four times on one PR (#361) today, interleaved with runs that produced full, high-quality reviews:

head	outcome
0e94400	crash, no verdict ($0.0000, 16 s)
30e2932	genuine review, 6 findings
ba76708	crash, no verdict -> manual rerun_failed_jobs produced a genuine review ($2.99)
c79bb12	crash, no verdict

The important datum is row 3: a separately-triggered re-run of the identical commit produced a complete review. So the failure is not deterministic in the diff, the head, or the prompt -- it is per-invocation, and re-running is a real (if manual and costly) workaround.

Suggested direction

Two things seem worth separating:

1. Diagnosis. The resolve-outcome step currently cannot distinguish this from the other generic failures it reports. The near-instant setup-bun: skipped on both attempts suggests the action exits before doing any work; capturing and surfacing why (the action's own early-exit reason, or the absence of an execution file vs. an empty one) would turn this from "review broke somehow" into something actionable.
2. Recovery. Since an independent re-invocation demonstrably clears it, the existing gha#185 retry may simply need to cover this signature too -- but note the retry already runs here and short-circuits the same way, so a same-run retry may share whatever state causes it. A genuinely fresh invocation may be required, which is a different fix from the current retry.

Repro

PR #361. Crashing runs: 30490409834 (before re-run), 30491512349. The successful manual re-run of the first is in that same run's later attempt, which posted this review.

Filed from a session driving #361, where this cost several rounds of babysitting and two manual re-runs.

[dem-extra1]

A fifth occurrence on #361, with a different signature — the retry hangs instead of short-circuiting

Head 7916a20, run 30495321836, job 90722669747. This one is worth recording here rather than as a separate issue, because it speaks directly to this issue's own "Suggested direction" point 2.

The step timings, from get_workflow_job:

step	status	timing
Run Claude Code Review (attempt 1)	success	22:13:17 → 22:14:09 (52 s)
Fail the check if the review did not complete (attempt 1)	success	22:14:10 (detected a stub)
Retry Claude Code Review after a stub result	in_progress	started 22:14:10, still running at 22:41 (~27 min)
everything after it (resolve outcome, post review, post cost)	pending	—

So the gha#185 stub machinery worked exactly as designed: attempt 1 ran for a real 52 seconds, produced a stub, the guard set stub_review=true, and the retry launched. The retry is then the thing that never returns.

Why this refines this issue rather than duplicating it. The four occurrences above all show both invocations short-circuiting in ~20 ms with setup-bun: skipped. This is the opposite shape: attempt 1 did real work, and the retry hangs indefinitely rather than exiting instantly. Same user-visible outcome — no verdict, nothing on the thread, require-review eventually red — reached by a different path.

That matters for the fix. Point 2 above hypothesised that a same-run retry "may share whatever state causes it," and this is direct evidence for that hypothesis being about more than the short-circuit: whatever the retry inherits can also make it hang. A recovery design that assumes the retry either works or fails fast will sit here for the full timeout-minutes before the job even reports, which is the worst case for an ARDI loop — a check that is neither green nor red for the better part of an hour, with no signal to act on.

Two things this suggests adding to the direction already sketched:

1. The retry needs its own bound, shorter than the job's, so a hung retry degrades to a reportable failure rather than consuming the whole timeout. Right now the only bound is timeout-minutes on the job, which also covers attempt 1 and every post-step.
2. A stub whose retry hangs is diagnostically distinct from a stub whose retry stubs, and the resolve-outcome step should be able to say which happened. Both currently land in the same generic branch, so the thread cannot tell a reader whether re-running is likely to help.

No manual re-run spent on this one: the run is still in_progress, so there is nothing to re-run yet, and #361 has a genuine external approval at this exact head from the other configured reviewer.

---

Generated by Claude Code