Bundle-apply race: safe_outputs fetch-depth=1 loses ancestor commits between agent and safe_outputs jobs

[norrietaylor]

Version: gh-aw v0.72.1

Symptom

Worker-style chores (create-pull-request safe output) intermittently fail at the safe_outputs git fetch <bundle> step with:

error: Repository lacks these prerequisite commits:
error: <SHA> 
##[error]Failed to apply bundle: The process '/usr/bin/git' failed with exit code 1
##[error]✗ Message 1 (create_pull_request) failed: Failed to apply bundle

Observed on worker-fix runs in gominimal/min-aw after another PR merged to main between the agent job and the safe_outputs job.

Root cause

The lock-file's safe_outputs job checks out the host repo with actions/checkout at fetch-depth: 1. Then it runs git fetch origin main and git fetch <bundle>. The bundle was generated by the agent based on whatever main was at agent-time. If main advanced between agent-time and safe_outputs-time (e.g., a different PR merged), the bundle's base commit is no longer reachable from the shallow tip → Repository lacks these prerequisite commits.

Reproduction is racy but reliable when:

1. Agent computes patch against main = SHA A at T1.
2. PR P merges to main at T2, advancing to SHA B (with A as ancestor).
3. Safe_outputs runs at T3, checks out main with fetch-depth: 1 → only B in local repo, A not present.
4. git fetch <bundle> fails because the bundle's base SHA = A is unreachable.

Concrete failing run: https://github.com/gominimal/min-aw/actions/runs/25904423290

• Bundle's prerequisite SHA: 172f87a830f57a29470efe7646d141069434a893 (was main HEAD when the agent ran; corresponds to a PR merge that happened just before)
• Main HEAD when safe_outputs ran: an advanced commit that descended from 172f87a but fetch-depth: 1 only had the tip

Why fetch-depth: 1 isn't enough here

The safe_outputs step's checkout is fresh — actions/checkout doesn't reuse the agent job's working tree. So even though the agent had access to main@A when it built the bundle, that history is gone by the time safe_outputs runs. git fetch <bundle> needs A reachable in the local repo, but the shallow clone only has the current tip.

Suggested fixes (any of the following)

1. Bump fetch-depth on the safe_outputs checkout step to a larger value (50? 100?) — covers typical PR-merge races.
2. Unshallow before bundle apply: after the existing git fetch origin main, add git fetch --unshallow origin main (or git fetch --depth=2147483647) when applying a bundle.
3. Fetch the bundle's base SHA explicitly: bundles already encode their base. Parse it and git fetch origin <base-sha> before git fetch <bundle>.
4. Have the safe_outputs handler retry once with --unshallow if the first apply fails with lacks these prerequisite commits.

Workaround for consumers

None at the consumer level — the safe_outputs job is compiled into the lock file by gh-aw. Repo owners can avoid the race by not merging other PRs while a chore-fix is in flight, but that's brittle. The daily cron retry helps because the second attempt is usually against a stable main, but agents can keep filing failure-report issues if the race repeats.

Related

• Failure-report safe-output fires when this happens, filing a new issue per failed run — amplifies noise during clearance loops.