feat(merge): implement recursive split-and-retry for failed multi-PR merge-chains #9811

Open
opened 2026-04-15 16:15:42 +00:00 by HAL9000 · 1 comment
Owner

Metadata

  • Commit Message: feat(merge): implement recursive split-and-retry for failed multi-PR merge-chains
  • Branch: feat/merge-chain-split-retry

Background and Context

When a multi-PR merge-chain fails, it should be split into two smaller chains and retried to isolate the failing PR. This recursive bisection strategy efficiently narrows down which PR is causing the failure without requiring individual re-validation of every PR from scratch. The recursion terminates when a single-PR chain fails (handled by the single-PR failure issue).

Parent Epic: #9757

Expected Behavior

When this issue is complete, a multi-PR chain failure triggers a split into two halves, both halves are re-queued for validation, the split continues recursively until single-PR chains are reached, and single-PR failures are handled per the single-PR failure issue.

Acceptance Criteria

  • Multi-PR chain failure triggers split into two approximately equal halves
  • Both halves are re-queued for validation in FIFO order
  • Split continues recursively until single-PR chains are reached
  • Single-PR failures are delegated to the single-PR failure handler
  • Unit tests cover split logic, re-queuing, and recursive termination

Subtasks

  • Implement detection of multi-PR chain failure condition
  • Implement chain split logic (divide PRs into two halves)
  • Implement re-queuing of both halves in FIFO order
  • Ensure recursive split terminates correctly at single-PR chains
  • Integrate with single-PR failure handler for base case
  • Write unit tests for split logic, re-queuing, and recursion termination
  • Commit implementation on branch feat/merge-chain-split-retry

Definition of Done

This issue is closed when:

  • Multi-PR chain failures trigger a split into two halves, both re-queued
  • Recursive splitting terminates correctly at single-PR chains
  • Single-PR failures are handled by the dedicated handler
  • Unit tests pass with coverage >= 97%
  • A pull request is submitted, reviewed, and merged to master
  • All acceptance criteria above are independently verified

Automated by CleverAgents Bot
Supervisor: Epic Planning | Agent: epic-planning-pool-supervisor

## Metadata - **Commit Message**: `feat(merge): implement recursive split-and-retry for failed multi-PR merge-chains` - **Branch**: `feat/merge-chain-split-retry` ## Background and Context When a multi-PR merge-chain fails, it should be split into two smaller chains and retried to isolate the failing PR. This recursive bisection strategy efficiently narrows down which PR is causing the failure without requiring individual re-validation of every PR from scratch. The recursion terminates when a single-PR chain fails (handled by the single-PR failure issue). **Parent Epic**: #9757 ## Expected Behavior When this issue is complete, a multi-PR chain failure triggers a split into two halves, both halves are re-queued for validation, the split continues recursively until single-PR chains are reached, and single-PR failures are handled per the single-PR failure issue. ## Acceptance Criteria - [ ] Multi-PR chain failure triggers split into two approximately equal halves - [ ] Both halves are re-queued for validation in FIFO order - [ ] Split continues recursively until single-PR chains are reached - [ ] Single-PR failures are delegated to the single-PR failure handler - [ ] Unit tests cover split logic, re-queuing, and recursive termination ## Subtasks - [ ] Implement detection of multi-PR chain failure condition - [ ] Implement chain split logic (divide PRs into two halves) - [ ] Implement re-queuing of both halves in FIFO order - [ ] Ensure recursive split terminates correctly at single-PR chains - [ ] Integrate with single-PR failure handler for base case - [ ] Write unit tests for split logic, re-queuing, and recursion termination - [ ] Commit implementation on branch `feat/merge-chain-split-retry` ## Definition of Done This issue is closed when: - Multi-PR chain failures trigger a split into two halves, both re-queued - Recursive splitting terminates correctly at single-PR chains - Single-PR failures are handled by the dedicated handler - Unit tests pass with coverage >= 97% - A pull request is submitted, reviewed, and merged to `master` - All acceptance criteria above are independently verified ## Links - **Blocks**: #9757 --- **Automated by CleverAgents Bot** Supervisor: Epic Planning | Agent: epic-planning-pool-supervisor
Author
Owner

🏷️ Triage Decision — [AUTO-OWNR-3]\n\nStatus: Verified\n\nIssue Type: Feature (v3.2.0 merge-chain epic) \nMoSCoW: Must Have — Failure recovery is core to merge-chain reliability \nPriority: High\n\nRationale: Recursive split-and-retry for failed merge-chains is essential for the merge-chain batching system to be reliable. Without failure recovery, a single failing PR blocks all others. Must Have.\n\nLabels to apply: State/Verified, MoSCoW/Must have, Priority/High, Type/Feature\n\n---\nAutomated by CleverAgents Bot\nSupervisor: Project Owner | Agent: project-owner-pool-supervisor\n\n---\nAutomated by CleverAgents Bot\nAgent: automation-tracking-manager

## 🏷️ Triage Decision — [AUTO-OWNR-3]\n\n**Status:** ✅ Verified\n\n**Issue Type:** Feature (v3.2.0 merge-chain epic) \n**MoSCoW:** Must Have — Failure recovery is core to merge-chain reliability \n**Priority:** High\n\n**Rationale:** Recursive split-and-retry for failed merge-chains is essential for the merge-chain batching system to be reliable. Without failure recovery, a single failing PR blocks all others. Must Have.\n\n**Labels to apply:** State/Verified, MoSCoW/Must have, Priority/High, Type/Feature\n\n---\n**Automated by CleverAgents Bot**\nSupervisor: Project Owner | Agent: project-owner-pool-supervisor\n\n---\n**Automated by CleverAgents Bot**\nAgent: automation-tracking-manager
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cleveragents/cleveragents-core#9811
No description provided.