Repository navigation
perf(pr-pipeline): read pr-verify verdicts by exact name in pr-unblock and pr-feedback-dispatch #13004
Description
Refs: #12932
Problem
In the REST window 2026-11-03T22:52:41Z to 23:52:41Z, the dispatch job of pr-feedback-dispatch.yml was the top caller. Most of its calls come from the pr-verify FAIL-cap read in front of a dispatch, and nearly all of that read is spent re-listing every artifact page. It does this because the carried artifact listing is missing.
Baseline (measured from each job's api-routes annotation):
- 33 non-skipped
dispatchjobs, 523 REST calls in total. - 10 heavy jobs (9 pr-unblock dispatches and 1 sweep) spent 455 of them (87%), 36 to 71 each. The 23 light jobs spent 2 to 7 each.
- Top routes:
actions/runs/{n}/artifacts108 (.github/scripts/pr-merge/rotation.mjs:154newestTrustedRun, which checks up to 10 runs, reached throughlisting-carry.mjsfromverify-cap.mjs:138-153);actions/artifacts73 (babysit_verify_evidence.py:2148and:2178, every page);contents/*51;actions/workflows/{x}/runs46;graphql45;git/ref/*40. - In every heavy job, the carry costs about 15 calls (listing-carry 11, carry-run-cache 3, head-ref-map 1), finds nothing, and logs
no earlier artifact listing; the verdict reader lists every page. The reader then reads 6 to 7 fullactions/artifactspages. - The job and run id pairs are kept on the host that ran the measurement, at
.work/pr-verify-cut/dispatch-jobs.txt. That directory is not committed.
Evidence that the listing is missing: GET actions/artifacts?name=pr-merge-verify-listing returns total_count 9, and the newest is from 2026-11-03T03:22:28Z (run 41571354158). Nothing has been uploaded since. The upload step .github/workflows/pr-merge.yml:2146-2153 runs only on schedule and workflow_dispatch, and only when the listing read whole. It uses if-no-files-found: ignore with retention-days: 1, so a partial read uploads nothing and logs nothing. Once the last copies expire, every FAIL-cap read lists all artifacts.
#12932 is not this path: its commit 431f923 changes only the rerun-ci-status job and scripts/ci-rerun-ci-status.test.sh.
Done when
- Move the verdict readers to exact-name index reads. Likely cause, UNVERIFIED until a dispatch log confirms it: feat(source-control): commit the legacy FAILs file to turn on FAIL index mode #12558 (FAIL index mode) merged 2026-11-03T03:28:44Z, six minutes after the last listing. In index mode the merge job reads verdicts by exact name and never writes
verify-listing.json, so the upload has nothing to upload. Move the pr-unblock and pr-feedback-dispatch verdict readers (verify-cap.mjs->rotation.mjs:154,babysit_verify_evidence.py:2148and:2178) to the same exact-name index reads, so they no longer depend on a carried listing. - Only if a listing reader survives item 1: have it find the carried artifact with one
actions/artifacts?name=pr-merge-verify-listingcall, checked against the trusted run list it already reads, instead of checking up to 10 runs. Also log a notice when a listing is partial or missing, instead of skipping the upload silently (pr-merge.yml:2146-2153). - Short-circuit wasted reads. 6 of the 10 heavy reads ended
refused verify:missing (), not its FAIL cap; the round runs under its own caps, spending about 30 calls each without changing the dispatch decision. Detect that outcome before the full read. - Re-measure. Run the same count over a 1-hour window after the change and compare it with the baseline above: calls per heavy job and the total for
dispatch.
Notes
- Owner lane: poteto (pr-merge area).
pr-merge.ymlis a workflow file, so the change is pushed from a host session, not a lane. - The hub counted 488 calls for this job and this measurement counted 523. The gap is likely core calls split across two reset times (one annotation reads
core-by-reset=…:19,…:18, i.e. 23:49:34Z and 23:52:41Z). UNVERIFIED.
Activity
github-actions commentedon Nov 4, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
I understand this as a request to cut REST calls in the pr-unblock and pr-feedback-dispatch verdict reads. Those reads would use exact-name index reads, so they no longer depend on the carried
pr-merge-verify-listingartifact, which has not been uploaded since 2026-11-03. It also asks for a short-circuit on reads that endverify:missing, and for a re-measurement over a 1-hour window.The suspected cause (#12558 index mode) is marked unverified, so a dispatch log should confirm it before the change. The re-measurement and the
pr-merge.ymlpush need a host session, so admission routes them as host work. I found no likely duplicate among the open issues.Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Nov 4, 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; its body or a criterion names .github/workflows/pr-feedback-dispatch.yml, .github/workflows/pr-merge.yml, which the issue lane cannot push (patch-protected-path); a builder session takes it; it carries host-run. 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 Nov 4, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.melodic-automation-lanes commentedon Nov 4, 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: Make the pr-unblock and pr-feedback-dispatch FAIL-cap reads use exact-name index reads instead of the carried listing, add a pre-read short-circuit for verify:missing, and log partial or missing listings.
Related work
Open questions
RECOMMENDED: Yes. The owner or a host session attaches one heavy dispatch log showing the 'no earlier artifact listing' line, and the work waits for it. Basis: judgment
RECOMMENDED: Pass the legacy file path in from verify-cap.mjs and the two dispatch workflows, and keep the gating as is. Basis: .base/plugins/source-control/skills/babysit-prs/scripts/babysit_verify_evidence.py:2704
RECOMMENDED: Defer it unless a listing reader remains after item 1. If one does, add the partial-or-missing notice at pr-merge.yml:2143-2152 in this issue. Basis: .base/.github/workflows/pr-merge.yml:2143
RECOMMENDED: Make one exact-name index read for the PR head SHA and skip the full read when no verdict exists, with a test showing the dispatch decision is unchanged. Basis: judgment
RECOMMENDED: Yes. Keep the code and test changes as the unattended part, and make the workflow push and the re-measure host checks. Basis: judgment
Sources read
To answer, post a comment that starts with this line:
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.kyle-sexton commentedon Nov 4, 2026
Related measurement gap. The same full listing also blocks per-PR metrics.
GET actions/artifactsreturned HTTP 500 on 7 of 9 calls between 02:40Z and 02:50Z on 2026-11-04, and one answer came back with an empty page 2 while reportingtotal_count18,023.workflow_runonmainwith an emptypull_requestslist, so only thepr-verify-<pr>-<sha>-<verdict>artifact names tie a run to its PR.run-name:inpr-verify.ymlthat carriesgithub.event.workflow_run.pull_requests[0].numberand the head SHA. That expression is already used in the concurrency group atpr-verify.yml:86. Each run'sdisplay_titlewould then name its PR, andactions/workflows/387380935/runs?created=<range>could count runs per PR without touching the artifact listing.skippedruns, 1,617 in one 2-day window. A reader filters those onconclusion, and whether that page cost is acceptable is UNVERIFIED.Posted by host-run Lane 5. This was generated by AI.
kyle-sexton commentedon Nov 4, 2026
One more full listing on a gate path: the cold merge-queue pre-check. Not covered by this issue's items so far.
.github/workflows/pr-require-checks.yml:6529-6538, on main at the fetch of 2026-11-04T04:40Z. With no carried run cache, ci-status pagesactions/artifacts?per_page=100with--paginateonly to computecold_cost.listing_pages=$(((total + 99) / 100 + 1)),:6537), per cold entry.per_page=100at 04:35Z, whileper_page=1answered 200 at 04:40Z. Name-filtered reads kept working. So every cold entry is held while the listing is down.babysit_verify_evidence.pyReader._targeted), so the formula'slisting_pagesand3 * failsterms describe a read that no longer happens.Whoever builds this issue can take it in the same change. Lane 5 is not building it.