fix(pr-review): unbreak reviews — stub must not forward lsp_pilot_variant to the pinned channel - #1048
Conversation
…channel (unbreak reviews) Every pr-review run has been failing with startup_failure since #1034 merged. Root cause: release-channel skew. #1034 modified the thin ring-0 caller stub (pr-review-trigger.yml) to forward a new `lsp_pilot_variant` input to `pr-review.yml@pr-review/next`, but that pinned channel (ded84ce) is behind #1034 and does NOT declare the input. Passing a `with:` key the called reusable doesn't declare is an invalid workflow → startup_failure on EVERY review (even with an empty value, and for event triggers). Fix: remove the premature `lsp_pilot_variant` dispatch input + its forwarding from the stub, restoring it byte-for-byte to its pre-#1034 `with:` set. The stub must not forward an input the pinned channel doesn't yet support. pr-review.yml on main keeps the input/env logic; the stub forwarding can be re-added once `pr-review/next` is advanced (via cut-release.sh) to a commit that declares it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016Y3xW3cnB5wscv4SmjSNEr
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
|
Warning Review limit reached
Next review available in: 55 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Pull request overview
This PR is a production hotfix to restore pr-review-trigger workflow execution by removing an undeclared reusable-workflow input (lsp_pilot_variant) from the thin caller stub, which was causing startup_failure when calling the pinned pr-review/next channel.
Changes:
- Removes the
workflow_dispatchinput definition forlsp_pilot_variantfrompr-review-trigger.yml. - Stops forwarding
lsp_pilot_variantin thewith:block to the pinned reusablepr-review.yml@pr-review/next, avoiding invalid-input startup failures.
…fety check The guard added in #1034 asserted the ring-0 stub FORWARDS lsp_pilot_variant — the exact behaviour that startup_failed every review (the stub pins @pr-review/next, which doesn't declare the input). Invert check_trigger so it now fails if the stub declares/forwards the input ahead of the pinned channel, matching the revert in the previous commit. This both unbreaks the guard on this PR and would have caught #1034 before merge. Re-enable procedure documented in the module docstring: advance pr-review/next to declare the input, then re-add the stub forwarding and flip this check back. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016Y3xW3cnB5wscv4SmjSNEr
|
Dev-Lead — fix-bot-comment (no-changes)Agent reasoning |
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).
…iant to the pinned channel (#1048) Production hotfix: #1034 made the ring-0 trigger stub forward a lsp_pilot_variant input that pr-review.yml@pr-review/next does not declare, causing startup_failure on every review. Restore the stub's with: block to the pre-#1034 set. Re-add forwarding only after pr-review/next is advanced to declare the input (epic #839/#844).



🔴 Production hotfix — every pr-review has been failing with
startup_failureSince #1034 merged (2026-07-03), every
pr-review-triggerrun has ended instartup_failure(confirmed across the last 15+ runs onmain). No PR is getting reviewed.Root cause — release-channel skew
#1034 modified the thin ring-0 caller stub (
pr-review-trigger.yml) to forward a newlsp_pilot_variantinput topr-review.yml@pr-review/next. But the pinned channelpr-review/next(ded84ce) is behind #1034 and does not declare that input. Passing awith:key the called reusable doesn't declare is an invalid workflow →startup_failureon every review — even with an empty value, and for event-triggered runs.This is the thin-caller-stub hazard called out in CLAUDE.md / the stub's own header ("this file only changes when the ring-0 channel itself changes"): the stub was changed to forward an input ahead of the channel that defines it.
Fix
Remove the premature
lsp_pilot_variantdispatch input + its forwarding from the stub, restoring itswith:block byte-for-byte to the pre-#1034 set (18 deletions, one file). Nothing else changes.pr-review.ymlonmainkeeps itslsp_pilot_variantinput + env/gating logic — it's harmless there. The stub forwarding should be re-added only afterpr-review/nextis advanced (viacut-release.sh --channel) to a commit that declares the input, so the stub and the channel it pins stay in lockstep.Validation
pr-review-trigger.ymlparses as YAML; nolsp_pilot_variantreference remains in the stub.main.Follow-up (separate, non-urgent)
Re-enable the pilot A/B on this repo's PRs the right way: advance
pr-review/nextto include #1034 first, then reintroduce the stub forwarding. Tracked against epic #839 / #844.🤖 Generated with Claude Code
Generated by Claude Code