What happened
On PR #2122, a human commented /fs-fix rebase. The fix agent ran for ~8 minutes (run 27603924320), successfully rebased the branch onto main, passed all validations (pre-commit, secret scan, schema check), and exited with code 0. However, post-fix.sh then attempted a plain git push (line ~255), which was rejected with non-fast-forward because the rebase rewrote commit history. The PR was subsequently closed without merging, and issue #1575 remains unresolved.
The script's push logic has an explicit comment explaining its rationale: 'Agents always create new commits (amend is in disallowedTools), so force-push is unnecessary and plain push is safer.' This assumption is correct for normal fix iterations but incorrect for rebase operations, which inherently rewrite history.
What could go better
The /fs-fix rebase command should actually work. Currently, the fix agent accepts and performs the rebase, but the result can never be pushed — making the command silently broken. This is high-confidence: the logs clearly show the agent succeeded and the push was rejected specifically due to non-fast-forward. The same failure will occur every time a human requests /fs-fix rebase.
Closed issue #411 previously changed post-code.sh from --force-with-lease to plain push, but that was for code agent PRs (new branches). The fix agent faces a different situation when asked to rebase an existing branch.
Proposed change
In internal/scaffold/fullsend-repo/scripts/post-fix.sh, detect when the local branch has diverged from its remote tracking branch after the agent's work. When divergence is detected (i.e., the agent rebased rather than adding new commits), use git push --force-with-lease instead of plain git push. Specifically:
- After the agent completes, compare the local HEAD against the remote tracking branch with
git merge-base --is-ancestor origin/${BRANCH} HEAD. If the remote is NOT an ancestor of HEAD, the branch was rebased.
- In that case, push with
--force-with-lease to safely overwrite the remote branch (force-with-lease still rejects if someone else pushed in the meantime).
- Update the comment explaining the push strategy to document this rebase case.
Alternative approach: if force-push is deemed too risky for the fix agent, reject the rebase instruction early — either in the dispatch shim or at the start of the fix agent — with a clear error message telling the human to rebase manually.
Validation criteria
A /fs-fix rebase command on a PR whose branch is behind main should result in the rebased branch being successfully pushed and the PR updated. Test by: (1) creating a test PR with a branch behind main, (2) commenting /fs-fix rebase, (3) verifying the fix agent run completes with success conclusion (not just agent exit code 0) and the PR branch is updated. The next 3 /fs-fix rebase invocations in production should succeed without non-fast-forward rejections.
Generated by retro agent from fullsend-ai#2122
What happened
On PR #2122, a human commented
/fs-fix rebase. The fix agent ran for ~8 minutes (run 27603924320), successfully rebased the branch onto main, passed all validations (pre-commit, secret scan, schema check), and exited with code 0. However,post-fix.shthen attempted a plaingit push(line ~255), which was rejected withnon-fast-forwardbecause the rebase rewrote commit history. The PR was subsequently closed without merging, and issue #1575 remains unresolved.The script's push logic has an explicit comment explaining its rationale: 'Agents always create new commits (amend is in disallowedTools), so force-push is unnecessary and plain push is safer.' This assumption is correct for normal fix iterations but incorrect for rebase operations, which inherently rewrite history.
What could go better
The
/fs-fix rebasecommand should actually work. Currently, the fix agent accepts and performs the rebase, but the result can never be pushed — making the command silently broken. This is high-confidence: the logs clearly show the agent succeeded and the push was rejected specifically due to non-fast-forward. The same failure will occur every time a human requests/fs-fix rebase.Closed issue #411 previously changed
post-code.shfrom--force-with-leaseto plain push, but that was for code agent PRs (new branches). The fix agent faces a different situation when asked to rebase an existing branch.Proposed change
In
internal/scaffold/fullsend-repo/scripts/post-fix.sh, detect when the local branch has diverged from its remote tracking branch after the agent's work. When divergence is detected (i.e., the agent rebased rather than adding new commits), usegit push --force-with-leaseinstead of plaingit push. Specifically:git merge-base --is-ancestor origin/${BRANCH} HEAD. If the remote is NOT an ancestor of HEAD, the branch was rebased.--force-with-leaseto safely overwrite the remote branch (force-with-lease still rejects if someone else pushed in the meantime).Alternative approach: if force-push is deemed too risky for the fix agent, reject the rebase instruction early — either in the dispatch shim or at the start of the fix agent — with a clear error message telling the human to rebase manually.
Validation criteria
A
/fs-fix rebasecommand on a PR whose branch is behind main should result in the rebased branch being successfully pushed and the PR updated. Test by: (1) creating a test PR with a branch behind main, (2) commenting/fs-fix rebase, (3) verifying the fix agent run completes with success conclusion (not just agent exit code 0) and the PR branch is updated. The next 3/fs-fix rebaseinvocations in production should succeed without non-fast-forward rejections.Generated by retro agent from fullsend-ai#2122