Parent: #1936
Problem
An earlier roadmap item (#1941) collapsed most repeated check/status reads onto a shared per-request cache used by the readiness check, the maintenance planner, and the post-publish boundary. Live observation shows two remaining call sites — the staged-merge approval-queue acceptance path and the auto-maintain action executor's own pre-mutation re-check — call the CI-status fetch directly, bypassing that shared cache entirely, even when one of the other three call sites already fetched the identical commit SHA moments earlier in the same review/maintenance pass. In a live sample, the same commit SHA was independently re-fetched a couple dozen times across these uncoordinated call sites within a short window.
Requirements
- Thread the existing shared per-request cache (or an equivalently narrow, short-TTL shared memo keyed by repo+SHA) into the two call sites that currently bypass it.
- Preserve the requirement that these are act-boundary reads (merge/close eligibility) — this is a coalescing fix (share a fetch made moments ago within the same pass), not a staleness-tolerance fix. Do not introduce a cache with a TTL long enough to risk acting on stale CI state.
Deliverables
- The approval-queue accept-time re-verification and the action-executor's pre-mutation re-check both read from the same shared per-pass cache the other three call sites already use, only fetching fresh when that cache doesn't already have this exact SHA from earlier in the same pass.
- A regression test proving: multiple reads of the same SHA within one pass produce exactly one network fetch, and a SHA change still forces a fresh fetch.
Acceptance criteria
- No duplicate CI-status fetches for the same SHA within a single review/maintenance/approval pass.
- No change to merge/close eligibility decisions — this must remain semantically identical to today's always-fresh-within-pass behavior, just deduplicated.
Expected outcome
The remaining redundant CI-status polling volume drops without touching any decision logic, closing the gap #1941 didn't fully cover.
Parent: #1936
Problem
An earlier roadmap item (#1941) collapsed most repeated check/status reads onto a shared per-request cache used by the readiness check, the maintenance planner, and the post-publish boundary. Live observation shows two remaining call sites — the staged-merge approval-queue acceptance path and the auto-maintain action executor's own pre-mutation re-check — call the CI-status fetch directly, bypassing that shared cache entirely, even when one of the other three call sites already fetched the identical commit SHA moments earlier in the same review/maintenance pass. In a live sample, the same commit SHA was independently re-fetched a couple dozen times across these uncoordinated call sites within a short window.
Requirements
Deliverables
Acceptance criteria
Expected outcome
The remaining redundant CI-status polling volume drops without touching any decision logic, closing the gap #1941 didn't fully cover.