Read the dispatched item number from the workflow input - #283
Conversation
`triage-single-item` only runs on `workflow_dispatch`, but its "Get item details" step looked the item up with `context.issue.number`. A `workflow_dispatch` payload has no issue, no pull request and no number, so github-script resolved that to `undefined` and the lookup 404'd. The job has therefore failed on every dispatch since a482e38, taking the whole single-item path with it - including every run the unlabeled sweep dispatches. The number is already available as the `issue_number` workflow input, which the apply job downstream reads. This step now reads the same input through the environment, matching that job. The one remaining `context.issue.number` is in `apply-new-item-labels`, where it is correct: that job needs `triage-new-item`, which runs only on `issues` and `pull_request_target`, and those payloads do carry a number. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RdDrWtq6hWWuDDQDxQx94G
|
Warning Review limit reached
Next review available in: 54 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
triage-single-itemhas failed on every dispatch since a482e38 (Apr 22). It is the last of the three bugs that stood between the triage workflow and working end to end; #280 fixed the other two.The bug
The job is gated to
workflow_dispatch:but its "Get item details" step looked the item up with
context.issue.number. github-script derives that from the event payload —payload.issue, elsepayload.pull_request, elsepayload— and aworkflow_dispatchpayload has none of the three. It resolves toundefined, andissues.get404s.Because the job is dispatch-only, this is not an edge case: the lookup could never have succeeded. Every run of the single-item path failed at step two, which includes every run the unlabeled sweep dispatches — so the sweep would have gone on producing nothing even after #280 taught it to find pull requests.
The fix
The number is already passed as the
issue_numberworkflow input, and the apply job downstream reads it from the environment. This step now does the same, so both halves of the job agree on where the number comes from.Scope
The other
context.issue.numberin this file, inapply-new-item-labels, is correct and is left alone: that jobneeds: triage-new-item, which runs only onissuesandpull_request_target, and those payloads do carry a number. I checked every use in the file rather than only the one that failed.Verification
actionlint passes. The behavioural check needs this on
mainfirst, sinceissue-triage.ymlresolves the reusable workflow at@mainregardless of the ref it is dispatched from — dispatch with anissue_numberand the run should reach the model and apply labels, rather than failing at "Get item details".Note that the repository currently has no open unlabeled items, so an empty-
issue_numbersweep will legitimately reportFound 0and is not a useful test of this. Dispatch with an explicit number instead.Generated by Claude Code