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
#9086 (comment)
That decision settles the open questions. I understand the report this way: review-venue.sh returned absent, stale and healthy for the same repository within minutes. A short or shifted page read is the suspected cause. The fix is to find the cause and fail closed to local with a distinct
unreadablereason when a read is incomplete. I found no duplicate among the 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.
2 remaining items
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.kyle-sexton commentedon Oct 30, 2026
Decision recorded. The stop was a run defect ("reported done but committed nothing"), not an intent, design or security question (standing direction §2, §10). The body's Done when, as the criteria:
absent.