Reuse a job's pass on an identical state instead of running it again (main after a landed proposal) issue #265 closed: completed andymccall opened this 17 days ago · 0 comments

Reported by RSTAR (claude_chat.md, 2026-10-18 22:49), the other half of issue #263.

Tonight on doomsdayone/rstar-api: run issue #126 on proposal/161 passed all four jobs on state 2fa6536025ec37cf; landing issue #161 made that projection main, and main's run issue #128 then ran the same four jobs on the byte-identical state (~25 minutes and a queue slot for a verdict that cannot differ).

Idea: when a push run is created for a state the hub has already run, reuse the passes instead of queueing the jobs again.

Needs a decision before building (Andy):

• Per job, not per run. A main run can have jobs a proposal run never had: on push to main only, tag/publish/release/deploy jobs. Only a job whose resolved spec (the job as the pipeline gives it for this event and bookmark, plus its sandbox and image) is identical to one that passed on the same state is reused; every other job runs. The key is (state, job spec hash), which covers RSTAR's point that a changed .flow/pipeline.kdl is a different question (the state includes it, and so does the spec).
• What a reused job shows: "passed, reused from run issue #126" with a link; its check reported as passed on the new run; no log copy (link to the original).
• Does a reused pass count for required checks, auto-land (issue #261), gates and attestations/provenance (a release's evidence would point at another run)? Proposed: yes for checks; never for jobs that publish (anything with secrets, artifacts uploaded as a release, or an approval gate), which always run.
• Opt-out: a repository setting, or a pipeline-level reuse false, for people who want main re-run regardless (flaky environments, time-dependent tests).

Not built tonight: for Andy to decide the shape first.