root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(merger): stop phantom-merge guard stranding tasks whose commit already landed

Browse Source 
Tasks were getting stuck in In Review with "verification fix succeeded but no
merge commit could be created" even though the merge commit was already on
main. Verification failures on attempt 1 were being swallowed by the smart-
conflict-resolution retry path, triggering attempt 2 with a stale baseline,
and the in-merge-fix finalizer would then fail its phantom-merge check.

- Propagate VerificationError out of executeMergeAttempt so the in-merge fix
  runs once on attempt 1 with the correct preAttemptHeadSha baseline.
- In commitOrAmendMergeWithFixes, recognize "task already on HEAD" via the
  Fusion-Task-Id trailer (line-anchored match) and treat the no-progress
  finalize as success instead of tripping the guard.
- Add real-git regression test plus update merger.test.ts call counts to
  reflect the (now correctly absent) attempt-2 AI agent.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
gsxdsm
2026-05-08 06:46:12 -07:00
parent 9670a003ca
commit 97e039b47a
4 changed files with 120 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
.changeset/fix-merger-phantom-merge-false-negative.md Normal file
View File

@@ -0,0 +1,10 @@
---
"@runfusion/fusion": patch
---
Fix tasks getting stuck in In Review with "verification fix succeeded but no merge commit could be created" even when the merge commit had already landed on main.
Root cause: when attempt 1 of the merge hit a verification failure (test command failed) under default smart conflict resolution, the catch in `executeMergeAttempt` swallowed the error and returned `false`, triggering a redundant attempt 2. Attempt 2 captured a stale `preAttemptHeadSha` (the AI commit from attempt 1), found the branch already merged, ran the in-merge fix, and the finalizer's phantom-merge guard then saw `!hasStaged && !headMoved` against the wrong baseline — even though the task's content was already on HEAD.
- `executeMergeAttempt` now propagates `VerificationError` directly so the in-merge fix runs once on attempt 1 with the correct baseline. Auto-conflict-resolution can't fix a verification failure, so retrying with attempt 2 was always wrong for this error.
- `commitOrAmendMergeWithFixes` adds a defense-in-depth check: if HEAD already carries the task's `Fusion-Task-Id` trailer, treat the no-progress finalize as success rather than tripping the phantom-merge guard. The trailer match is anchored to line boundaries so unrelated task IDs in the body can't false-positive.