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

fix(FN-4417): stop false-positive branch contamination from stale baseCommitSha

Browse Source 
The contamination check at executor.ts was reusing task.baseCommitSha as
its reference SHA. That field is intentionally preserved across resumed
sessions for stable diff math, which means it can lag behind main by
many commits. Passing it to assertCleanBranchAtBase caused every
legitimately-merged commit on main since the stale SHA to be reported
as a foreign task-attributed contamination commit, pausing the task
with pausedReason=branch-cross-contamination.

FN-4403 was the trigger case: a pooled worktree was force-reset to
current main by WorktreePool.prepareForTask (correctly), then the
executor immediately ran assertCleanBranchAtBase(rootDir, branch,
staleBaseCommitSha, taskId) and flagged 157 commits across ~39
unrelated FN-* tasks as contamination. FN-4417 itself then hit the
same bug when it tried to start, blocking the board.

Two fixes, both in packages/engine/src/executor.ts:

1. New resolveContaminationBaseRef(worktreePath) computes a fresh
   merge-base against origin/main or main and is used in place of
   resolveDiffBaseRef for the contamination check. It never reads
   task.baseCommitSha and never falls back to HEAD~1 (which on a
   force-reset pooled branch would be a main commit and re-introduce
   the same false positive at smaller scale). Returns undefined on
   git failure so the caller treats it as check skipped.

2. captureBaseCommitSha gains an explicit { isResume: boolean }
   parameter and only preserves an existing baseCommitSha when
   isResume is true. On fresh/pool acquisitions the branch was just
   force-reset to current main, so the stored value is stale by
   definition. Always recapture in that case. Diff-base stability
   across resumed sessions (FN-4309/FN-4383) is preserved by passing
   isResume: true on resume; the existing executor call site is
   already gated on non-resume and passes false.

Tests:
- executor-base-commit-capture.test.ts: updated to thread isResume
  through assertions and added a FN-4417 regression case that verifies
  a stale-but-ancestor baseCommitSha is recaptured (not preserved) on
  non-resume.
- executor-base-commit-capture.real-git.test.ts: FN-4309/FN-4383
  multi-session test now explicitly passes isResume: true on the
  second capture, matching the real resume code path.
- executor-contamination-base.test.ts (new): three focused tests for
  resolveContaminationBaseRef covering fresh-merge-base resolution,
  graceful failure when neither origin/main nor main resolves, and a
  structural guard that the function arity is 1 (no baseCommitSha
  parameter, so the bug cannot regress through that surface).

Verified: 4265 engine tests pass; tsc clean.

Fusion-Task-Id: FN-4417
This commit is contained in:
gsxdsm
2026-05-13 18:44:41 -07:00
parent ef34f0ab97
commit a2b494ddc0
5 changed files with 190 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
.changeset/fix-fn-4417-contamination-false-positive.md Normal file
View File

@@ -0,0 +1,5 @@
---
"@runfusion/fusion": patch
---
Fix false-positive `BranchCrossContaminationError` that paused tasks at start when their stored `baseCommitSha` was stale relative to `main`. The contamination check now computes a fresh merge-base against the integration branch instead of reusing the diff-stable `task.baseCommitSha`, and `captureBaseCommitSha` only preserves a prior stored value when resuming an existing worktree. Diff-base stability across resumed sessions is preserved (FN-4309/FN-4383 behavior unchanged).