claude-code-review's workflow_dispatch re-review posts a successful require-review check tied to the wrong commit SHA

[d-morrison]

What happened

While driving UCD-SERG/serocalculator#581 to clean, a @claude review comment re-triggered claude-code-review.yml via workflow_dispatch. That run (30058257164) posted a genuine, clean review comment ("Ready for merge") and its own review / require-review job succeeded.

But gh/the Checks API still shows review / require-review: failure for the PR's actual head commit (e87e840) --- the successful run's jobs all report head_branch: "main", head_sha: "dcfc203..." (the repo's main branch tip / the PR's base), not the PR's real head SHA. The check-run for the successful job is registered against the wrong commit, so it never supersedes the earlier, genuinely-cancelled require-review run (see #144) tied to the correct head SHA.

Net effect: a PR can have a fully clean, current review posted as a comment, plus a green require-review job, while the PR's actual head commit's required-status-check view still shows red --- because the passing check landed on the wrong SHA. gh run rerun <run-id> on the originally-cancelled (correctly-SHA'd) run would fix this, but the token available in that session (Claude Code Remote / MCP GitHub App) got 403 Resource not accessible by integration on both rerun-failed-jobs and rerun for that run, so no in-session recovery was available either.

Suspected root cause

Whatever step in claude.yml (or claude-code-review.yml) calls workflow_dispatch on claude-code-review.yml in response to an @claude review comment is likely not passing an explicit ref/head_sha input tied to the PR's actual head commit, so GitHub defaults the dispatched run's association to the default branch. This is the general GitHub Actions gotcha: "a workflow_dispatch run invoked without an explicit ref can be recorded against the default branch's SHA rather than the triggering PR's head SHA."

Suggested fix

• Have the dispatch step pass the PR head SHA explicitly (as a workflow input, or by checking out/dispatching with the correct ref) so the resulting check-run(s) attach to the actual commit under review.
• Alternatively/additionally, revisit issue Document the claude-review concurrency race that red-X's require-review #144's "possible follow-up" (treat a cancelled claude-review result as skipped rather than failure in require-review) --- that wouldn't fix the wrong-SHA attribution, but would at least stop a stale/cancelled run from red-X'ing the PR while a correctly-attributed run is pending.

Reproduction

1. Open a PR, get an automatic pull_request-triggered review.
2. Push a fix; the auto-triggered review races with (and is cancelled by) a concurrent workflow_dispatch re-review from a claude.yml agent run finishing around the same time (per Document the claude-review concurrency race that red-X's require-review #144).
3. The workflow_dispatch run itself succeeds and posts a real review + a green require-review job.
4. gh pr checks <N> (or the Checks API for the PR's actual head SHA) still shows require-review: failure, because the green job's check-run is attached to main's SHA, not the PR head's SHA.

Seen concretely on UCD-SERG/serocalculator#581, commit e87e840dbf0c8de76e22187c7a80cea5a88a3859: run 30058257164's jobs all report head_sha: dcfc203bc3a98ca3764811a224dae67ed5f6edd2 (the PR's base/main tip), not e87e840.

[github-actions]

👀 Picked up by workflow run #30058585640. Setup runs first; Claude itself responds after that.

[github-actions]

Opened draft PR up front: #286 — Claude is working on it now.

[d-morrison]

Update: on UCD-SERG/serocalculator#581, rebasing the PR branch onto current main (fresh push, new head SHA) produced an uncontested pull_request-triggered review run whose require-review job succeeded and attached correctly to the real head SHA --- confirming a rebase/fresh-push is an effective workaround when hit. Leaving the root-cause fix (explicit ref on the workflow_dispatch re-dispatch) open as the real fix.

---

Generated by Claude Code