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

fix(engine): rescue auto-merge handoff from stale mergeActive entries

Browse Source 
The 15s `scheduleMergeRetry` sweep was silently re-skipping in-review
tasks whose `mergeActive` entry leaked from a wedged prior attempt
(uncaught error inside `drainMergeQueue`, restart between push and
finally, etc.). FN-002, FN-004, FN-3898, FN-3899 all sat in in-review
until the 15-min maintenance loop logged "Auto-recovered: eligible
in-review task re-enqueued for merge".

Two changes:

* `reconcileStaleMergeActive()` runs before each 15s sweep. Any
  `mergeActive` taskId that isn't in `mergeQueue` and isn't the
  `activeMergeTaskId` is treated as leaked and dropped, so the next
  enqueue actually pushes through.
* The `task:moved → in-review` immediate handoff (`wireAutoMerge`) now
  logs every skip reason instead of returning silently, clears its own
  stale `mergeActive` entry before enqueueing, and identifies the task
  in its catch-block warning. `internalEnqueueMerge` also warns when a
  leaked entry causes a skip — the next regression won't be invisible.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
gsxdsm
2026-05-09 16:33:54 -07:00
parent 271166ad7c
commit d942c0c404
3 changed files with 64 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
.changeset/auto-merge-handoff-stale-mergeactive.md Normal file
View File

@@ -0,0 +1,8 @@
---
"@runfusion/fusion": patch
---
Fix in-review tasks getting stranded after pre-merge workflow completes. Two regressions piled up:
1. The `task:moved → in-review` immediate-handoff path silently no-op'd whenever `internalEnqueueMerge` short-circuited on a leaked `mergeActive` entry — and every skip reason ("paused", "blocker", "autoMerge off", "engine paused") returned without logging, so the silence was opaque. Each branch now logs at info or warn level, the handler clears its own stale `mergeActive` entry before enqueueing, and the catch block's message identifies the task instead of pretending the failure was always a settings read.
2. The 15s `scheduleMergeRetry` sweep ran `enqueueEligibleInReviewTasks` → `internalEnqueueMerge` blindly, so a leaked `mergeActive` entry from a wedged prior attempt would skip the same task on every poll forever. Tasks were only rescued by the 15-min maintenance recovery loop ("Auto-recovered: eligible in-review task re-enqueued for merge"). Added `reconcileStaleMergeActive()` which drops `mergeActive` entries that aren't queued and aren't the active merge target, and call it before each 15s sweep. `internalEnqueueMerge` also now warns when a leaked entry causes a skip, so the next regression is visible.