Post-fix/post-code push scripts should fetch before force-with-lease retry

[fullsend-ai-retro]

What happened

Fix run 29581025125 on agents#190 failed at the push step. The plain git push was rejected (non-fast-forward) because another process had pushed to the branch during the ~9-minute fix run. The script retried with --force-with-lease, but that also failed with 'stale info' because the local remote-tracking ref had not been updated since the initial clone. The entire fix run was wasted, causing a ~2 hour delay before a manual retry (29587936601) succeeded from a clean state.

What could go better

The push logic in scripts/post-fix.src.sh (lines 318-349) and the identical logic in scripts/post-code.src.sh retries with --force-with-lease on non-fast-forward rejection but does not run git fetch first. Without a fetch, --force-with-lease compares against the stale tracking ref from clone time. This makes the retry fail even for legitimate rebases where the agent's changes don't conflict with the concurrent push. The inline comment claims 'force-with-lease is safe: it still rejects if someone else pushed in the meantime' — which is true, but the rejection here is overly conservative because the stale ref doesn't reflect the current remote state. A git fetch before the retry would make the lease check accurate. Confidence: high — the failure mode is clearly reproduced in the run log, and the fix follows standard git best practices.

Proposed change

In scripts/post-fix.src.sh and scripts/post-code.src.sh, add git fetch origin "${BRANCH}" between the failed plain push detection and the --force-with-lease retry. The current flow is: plain push fails → detect non-fast-forward → git push --force-with-lease. Change to: plain push fails → detect non-fast-forward → git fetch origin "${BRANCH}" → git push --force-with-lease. This ensures the tracking ref is current so --force-with-lease correctly distinguishes 'my rebase diverged from what was already there' (safe to push) from 'someone else pushed new work I haven't seen' (reject). Both files contain identical push logic and should be updated together.

Validation criteria

The next fix or code agent run that encounters a non-fast-forward push rejection should succeed on the force-with-lease retry instead of failing with 'stale info'. Verify across the next 10 fix/code agent runs that no push failures occur due to stale tracking refs. The force-with-lease retry should still correctly reject when genuinely conflicting concurrent pushes occur.

---

Generated by retro agent from #190

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 7:19 PM UTC · Completed 7:23 PM UTC
Commit: 3eb6a6e · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: medium · Category: bug

Problem

The push retry logic in post-fix.src.sh and post-code.src.sh uses --force-with-lease after a non-fast-forward rejection but does not run git fetch first. The local tracking ref is stale from clone time, so the lease check rejects the push even when the agent's changes don't conflict with the concurrent push. This wastes entire agent runs and can cause multi-hour delays.

Root Cause

Both scripts follow this flow: plain push fails → detect non-fast-forward → git push --force-with-lease. The missing step is git fetch origin "${BRANCH}" before the retry. Without it, --force-with-lease compares against an outdated ref.

Recommended Fix

Insert git fetch origin "${BRANCH}" between the non-fast-forward detection and the --force-with-lease retry in both:

• scripts/post-fix.src.sh (section 4)
• scripts/post-code.src.sh (section 7b)

Then run make script-build and commit source + bundled files together.

Proposed Test Case

Test: force-with-lease retry fetches before pushing

1. Set up a local repo with a remote tracking branch
2. Push a concurrent commit to the remote (simulating another process)
3. Run the post-script push logic
4. Assert git fetch is called before --force-with-lease
5. Assert the retry push succeeds (no true conflict)
6. Separately test that --force-with-lease still rejects genuinely conflicting concurrent pushes

Validation

The next fix/code agent run encountering a non-fast-forward rejection should succeed on the force-with-lease retry. Verify across 10 subsequent runs that no push failures occur due to stale tracking refs.

---

Labels: This is a bug in the post-script push logic. Adding 'bug' label as it's a defect in existing functionality, and 'fix-agent'/'code-agent' since it affects both agent pipelines.

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 7:24 PM UTC · Completed 7:31 PM UTC
Commit: 3eb6a6e · View workflow run →

[fullsend-ai-prioritize]

RICE Priority Score: 4.05

Score breakdown

Dimension	Score	Reasoning
Reach	1.5	This bug affects the fix-agent and code-agent pipelines, which are core infrastructure serving all users of the platform. The race condition (concurrent push during an agent run) doesn't occur on every run, but it affects multiple customers across orgs whenever it triggers. Labels confirm both fix-agent and code-agent are impacted.
Impact	1.5	When triggered, the bug wastes an entire ~9-minute agent run and caused a ~2 hour delay before manual retry succeeded. This is a significant pain point — agent reliability degrades and developer time is lost to manual retries. A workaround exists (manual retry from clean state) but it's costly.
Confidence	0.9	Very high confidence. The issue includes detailed root cause analysis with specific file references (post-fix.src.sh lines 318-349, post-code.src.sh), a clear reproduction from run logs, and the fix follows standard git best practices. The triage agent confirmed the analysis.
Effort	0.5	Simple fix — add a single git fetch origin BRANCH line before the force-with-lease retry in two files, then run make script-build. The change is well-scoped with no design ambiguity.

Formula: (1.5 x 1.5 x 0.9) / 0.5 = 4.05