Repository navigation
perf(pr-merge): let the lane-room read reuse the merge job's post-merge answer (if still needed) #9646
Description
Problem
enable-auto-merge's lane-room read runs a full post-merge check of its own whenever the cheap freshness check misses, for example after main has moved since post-merge-dispatch computed its answer. The merge job in the same pr-merge run computes an answer of its own minutes later, at a newer head. The room cannot use it, because the two jobs run in parallel.
Proposal (build only if the numbers show a need)
Order the room read after the merge job's post-merge check, and take that answer. That removes the room's second full check. The cost is that arming waits for the gate job.
Measure first. Fetching full history in the enable-auto-merge checkout should bring the room's full check near the merge job's time (137 s in run 40078071511) instead of the 4+ min that timed out. Build this only if, after that change, the room still misses often enough to delay arms, or its full check still costs too much API budget per run.
Evidence: run 40078071511, where the enable-auto-merge "Arm and disarm" step logged lane room: {"unreadable":"babysit_verify_evidence.py lane-room exited SIGTERM: "...} after 4m04s.
Refs: #9577
Activity
github-actions commentedon Oct 24, 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: when the cheap freshness check misses, the lane-room read in enable-auto-merge runs its own full post-merge check, which timed out after 4m04s in run 40078071511. The proposal is to order the room read after the merge job and reuse its answer. This is conditional. First fetch full history in the enable-auto-merge checkout and measure. Build the reuse only if the room still misses often enough to delay arms, or costs too much API budget. The measurement is the part still to do. No likely duplicates found; related to #9577.
Automated triage, applied by the lanes App.
kyle-sexton commentedon Oct 26, 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.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: admission moved the issue to
status: confirmed; its comment says why.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: Measure the room's full-check misses and time now that full history is fetched, and build the reuse of the merge job's post-merge answer only if the numbers show a need.
Related work
Open questions
RECOMMENDED: No build yet: first compare pr-merge runs since 9647 for the room's full-check time and miss rate against the merge job's 137 s, and close the issue if the room is near that time and misses are rare. Basis: judgment: the issue says to build only if the numbers show a need, and no measurement is in the issue or the repository; the enable-auto-merge job already checks out with fetch-depth: 0 at .github/workflows/pr-merge.yml:1557.
RECOMMENDED: The owner should set it; a plausible bar is the room's own full check running on more than about 1 in 10 runs, or arming delayed by minutes. Basis: judgment
RECOMMENDED: Accept only if the measurement shows a need; the issue names this wait as the cost of the change. Basis: judgment
Sources read
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.kyle-sexton commentedon Oct 29, 2026
Re-triage. Not an owner stop. This is a performance item that the body already makes conditional on measurement. The refinement's bar for "a need", which it left to the owner, is set below from the issue's own evidence. The leftover
status: needs-decisionlabel comes off.Context on origin/main at 1ac46f0: the enable-auto-merge job checks out with full history, and the room is read from this run's post-merge report (
.github/workflows/pr-merge.yml, the "Read this run's post-merge report" step in enable-auto-merge). Since this issue was filed, #10475 and #10603 changed how the post-merge answer is reused, so the miss rate has to be measured on current runs.Build: the Automation Lanes session. The build, if one is needed, orders the room read after the merge job's post-merge check in
.github/workflows/pr-merge.yml, which the lanes App cannot push (.github/actions/resolve-config/patch-rules.json:3).agent-readystays off.Acceptance criteria:
unreadable, with run links.