fix(FN-8004): make AI merge rejections actionable and stranded merges retryable - #2160
Conversation
… retryable
Two follow-ups to FN-8004, both surfaced while watching its own merge livelock.
1. AI merge rejections lost their reasons.
The review prompt said BOTH "End with a single decision line" AND "Then list each
concrete reason as a bullet" — impossible to satisfy at once. Reviewers obeyed the
former and wrote their reasoning ABOVE the verdict, but extractRejectReasons only
scanned lines AFTER it. Every such rejection collapsed to the placeholder
"reviewer rejected the merge without a stated reason", which was then handed to the
corrective re-merge pass AS its instruction — so the pass had no actionable feedback
and merely re-rolled the merge.
Observed on FN-8004's merge: BOTH attempts ran reject(no reason) → corrective pass →
approve. Each wasted cycle cost ~7 min, stretching the merge past main's ~8-min churn
window so every attempt lost to a concurrent advance. The livelock was caused by the
lost-reason bug, not by a reviewer that genuinely objected twice and then relented.
The parser now recovers reasons from either side of the verdict (inline → after →
before, nearest-first, capped at 8 so a long transcript cannot flood the corrective
prompt), skipping severity/verdict/markdown scaffolding. The prompt ordering is now
unambiguous: reasons first, verdict last, nothing after it.
2. An orphaned merge-active stamp was un-retryable by hand.
The dashboard Retry gate rejected EVERY merge-active status ("Task is not in a
retryable state (current status: landing)"), while self-healing cleared stale stamps
automatically minutes later. So a merger killed mid-flight — crash, engine restart,
operator SIGTERM — blocked the operator's own escape hatch exactly when it was needed.
FN-8004 hit this: a killed merge left `landing` stamped and Retry 400'd for the full
sweep delay.
isStaleMergeActiveStatus now lives in the leaf merge-active-status.ts and is shared by
recoverStaleMergingStatus and the Retry gate, so the manual path can never be stricter
than the automatic one — the same one-concept-two-definitions bug as the FN-8004
transient classifier. A live merge stays protected by two independent signals: it holds
the in-process lease and refreshes updatedAt each phase. Staleness fails closed on an
unparseable timestamp.
The bypass feeds isInReviewRetry rather than only the gate: a bare gate bypass would
fall through to the generic branch and move fully-executed work to `todo`, re-running it.
Verified: gate green (294+122+63), lint clean, engine+dashboard typecheck clean,
verify:fast PASS, 70 merger-suite tests green. The route regression test was confirmed
non-vacuous — neutralizing the fix fails the two "now retryable" cases while the three
live-merge-protection cases still pass.
Fusion-Task-Id: FN-8004
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthroughThe PR centralizes merge-active staleness detection for self-healing and dashboard retries, allowing orphaned merge-active tasks to retry while protecting active or recently updated tasks. It also improves AI rejection-reason recovery and clarifies review prompt output ordering. ChangesStale merge retry
AI verdict recovery
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Operator
participant DashboardRetryRoute
participant SelfHealingManager
participant StaleMergePredicate
participant TaskStore
Operator->>DashboardRetryRoute: POST task retry
DashboardRetryRoute->>SelfHealingManager: read active merge lease and age floor
DashboardRetryRoute->>StaleMergePredicate: evaluate status, owner, and age
StaleMergePredicate-->>DashboardRetryRoute: retryable or blocked
DashboardRetryRoute->>TaskStore: clear status and error
TaskStore-->>DashboardRetryRoute: updated task
DashboardRetryRoute-->>Operator: HTTP response
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR improves recovery for stalled merge workflows. The main changes are:
Confidence Score: 5/5The latest changes look safe to merge.
Important Files Changed
Reviews (2): Last reviewed commit: "fix(FN-8004): align manual merge recover..." | Re-trigger Greptile |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/engine/src/__tests__/merger-ai-prompts.test.ts`:
- Around line 134-158: Extend the parseReviewVerdict regression coverage to
include a genuine reason before the REVIEW_VERDICT_MARKER and a closing code
fence after it, asserting that reasons excludes the fence and retains the real
reason. Keep the existing scaffolding, severity, and verdict-line filtering
assertions, and ensure the test covers both post-verdict and surrounding
markdown boundaries.
In `@packages/engine/src/merger-ai-prompts.ts`:
- Around line 131-145: Filter scaffolding consistently in the post-verdict loop
of the reason-extraction logic by applying isNonReasonLine before cleaning or
collecting lines, allowing valid preceding feedback to trigger fallback. Add a
regression case in packages/engine/src/__tests__/merger-ai-prompts.test.ts
covering a preceding reason followed by a trailing code fence, and assert the
invariant across both post-verdict and preceding-reason recovery surfaces.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 44e27a83-b91f-4c49-8771-f12c19b0cc5d
📒 Files selected for processing (9)
.changeset/fn-8004-merge-review-reasons-and-landing-retry.mdpackages/dashboard/src/__tests__/routes-task-retry-stale-merge-status.test.tspackages/dashboard/src/routes/register-task-workflow-routes.tspackages/engine/src/__tests__/merge-active-status.test.tspackages/engine/src/__tests__/merger-ai-prompts.test.tspackages/engine/src/index.tspackages/engine/src/merge-active-status.tspackages/engine/src/merger-ai-prompts.tspackages/engine/src/self-healing.ts
Fusion-Task-Id: FN-8004
Two follow-ups to FN-8004. Both were found by watching FN-8004's own merge livelock for 40 minutes — it turned out to be blocked by the very class of bug it was filed to fix.
1. AI merge rejections lost their reasons
The reviewer prompt said both of these:
Those are impossible to satisfy at once. Reviewers obeyed "End with" and wrote their reasoning above the verdict — but
extractRejectReasonsonly scanned lines after it. So every such rejection collapsed to the placeholderreviewer rejected the merge without a stated reason, and that placeholder was then handed to the corrective re-merge pass as its instruction. The pass got no actionable feedback and just re-rolled the merge.The evidence, from FN-8004's own merge — the pattern repeated across both attempts:
a3a3cc6a8(03:49)A reviewer that rejects and then approves identical content isn't objecting — the reason was being thrown away. Each wasted cycle cost ~7 minutes, stretching the merge past main's ~8-minute churn window so every attempt lost to a concurrent advance and rebuilt. The livelock was caused by the lost-reason bug.
Fix: the parser recovers reasons from either side of the verdict (inline → after → before, nearest-first so the closing argument leads, capped at 8 so a long transcript can't flood the corrective prompt), skipping severity/verdict/markdown scaffolding. The prompt ordering is now unambiguous — reasons first, verdict last, nothing after it.
2. An orphaned merge-active stamp was un-retryable by hand
The Retry gate refused every merge-active status (
Task is not in a retryable state (current status: landing)), while self-healing cleared stale stamps automatically minutes later. So a merger killed mid-flight — crash, engine restart, operator SIGTERM — blocked the operator's own escape hatch at exactly the moment they'd reach for it. FN-8004 hit this: a killed merge leftlandingstamped and Retry 400'd for the full sweep delay.isStaleMergeActiveStatusnow lives in the leafmerge-active-status.ts, shared byrecoverStaleMergingStatusand the Retry gate — so the manual path can never be stricter than the automatic one. This is the same one-concept-two-definitions bug as FN-8004's transient classifier, which is why it's worth fixing structurally rather than adding another special case.A live merge stays protected by two independent signals: it holds the in-process lease and refreshes
updatedAteach phase. Staleness fails closed on an unparseable timestamp.One subtlety worth reviewing: the bypass feeds
isInReviewRetryrather than only the gate. A bare gate bypass would fall through to the generic branch and move fully-executed work totodo, re-running finished work — a bug this fix could easily have introduced.Verification
verify:fastPASSACTIVE_MERGE_STATUSES(a merger can die in any phase, not just the reportedlanding), both live-merge signals, boundary conditions, fail-closed paths, and that pre-existing retry paths are unchanged. Test files carry the required## Symptom Verificationand## Surface Enumerationsections.🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Reliability
Tests