Repository navigation
fix(source-control): review-venue.sh gives absent, stale and healthy for the same repository minutes apart #9086
Description
Problem
plugins/source-control/skills/pull-request/scripts/review-venue.sh gives different verdicts for the same repository minutes apart, so /source-control:pull-request ready and prep run local AI reviews the CI lanes already cover. A run that wrongly reported ci healthy would instead skip a review that should run here.
Four runs against melodic-software/claude-code-plugins on 2026-10-22, 15:0x-15:2xZ, installed source-control 2.0.0:
- run 1 and 2:
code-review local absent: no recent pull_request run calls the code-review lane(same for security-review) - run 3:
code-review local stale: .github/workflows/pr-review-hosted.yml has no run with a verdict among its newest 100 - run 4 (under
bash -x, stderr discarded):code-review ci healthy: newest run with a verdict, 39801569024, succeeded at 2026-10-22T15:05:46Z
The lanes were running: #9050's checks show pr-review / claude-review-status and pr-review-security / security-review passing. Run by hand, the discovery jq at review-venue.sh:100-103 against page 1 of actions/runs?event=pull_request&per_page=100 finds both callers (workflow ids 374687473 and 374687472); 45 of those 100 runs reference the reusable review workflows.
The host was recovering from heavy IO wait at the time, so slow or partial gh api responses are a candidate cause (a response that parses but holds fewer runs, or a page that shifted as new runs arrived). Not confirmed.
Fix
Find why the same inputs give absent, stale and healthy: check whether a short or shifted page passes the length < 100 early break (:110) or the verdict scan, and fail closed to local with a distinct reason (unreadable) instead of absent when a page read is incomplete.
Done when
- Repeated runs against an unchanged repository give the same verdict.
- An incomplete read reports a reason that says so, never
absent.
Refs: #9082
Activity
github-actions commentedon Oct 22, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: review-venue.sh returns different verdicts (absent, stale, healthy) for the same repository minutes apart, so local AI reviews run when CI already covers them. The suspected cause is an incomplete or shifted
gh apipage. The fix is to find the cause and fail closed tolocalwith a distinctunreadablereason when a page read is incomplete.Nothing is missing to start. Reproducing the flaky read, for example by simulating a short or shifted page, should settle the root cause. No duplicates found among open issues.
Automated triage, applied by the lanes App.
github-actions commentedon Oct 26, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
melodic-automation-lanes commentedon Oct 26, 2026
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed
- [ ]criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 26, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.melodic-automation-lanes commentedon Oct 26, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: review-venue.sh reports a lane as
local unreadable(neverabsentorstale) when a workflow-runs page read is incomplete, and gives the same verdict on repeated reads of an unchanged repository.Acceptance criteria
.workflow_runsarray, treating it as unreadable instead of passing it to the discovery jq (currently.workflow_runs\[\]?at review-venue.sh:108 turns a missing key into no match).workflow_runslength with the responsetotal_count(or an equivalent completeness check) so a short or shifted page is not taken as the end of the listing at the-lt 100break (review-venue.sh:119)<lane> local unreadable: <detail>and neverlocal absent;absentstays only for a complete read with no calling workflowlocal unreadableand notlocal staleunreadablereason and say it runs the review locallyworkflow_runs, a short page, and a count mismatch, and each assertslocal unreadableand notabsentorstaleRelated work
Sources read
.workflow_runs\[\]?which tolerates a missing key, and breaks when a page holds fewer than 100 runs; no total_count checklocal absentwith no check of whether the page reads were completelocal stalewhen no verdict is foundunreadablestateabsentlines and exit 2 on unreadable state; no short-page casesAutomated refinement by the lanes App. Intake triages the issue again with it.
melodic-automation-lanes commentedon Oct 26, 2026
The work-resolve-issue lane stopped partway through this issue and needs a person.
Why, in the run's own words:
Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/40354760854
To retry, remove
needs-humanand addagent-readyagain.kyle-sexton commentedon Oct 27, 2026
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add
needs-human(orstatus: needs-decision) and name which of the three applies.