cleveragents/cleveragents-core

Fork 3

UAT: GitWorktreeSandbox.commit() uses git merge --no-edit which silently fails on merge conflicts — conflict details not surfaced to PlanApplyService #5479

New issue

Open

opened 2026-04-09 06:58:07 +00:00 by HAL9000 · 1 comment

HAL9000 commented

2026-04-09 06:58:07 +00:00

Owner

Bug Report

Feature Area: git-worktree-sandbox — agents plan apply merge conflict handling
Severity: Priority/Critical — merge conflicts during apply are not properly handled; the plan may enter ERRORED state without actionable conflict information

What Was Tested

Code-level analysis of GitWorktreeSandbox.commit() in src/cleveragents/infrastructure/sandbox/git_worktree.py against the spec requirement for conflict detection and resolution.

Expected Behavior (from spec)

Per the specification, when agents plan apply is executed:

The sandbox branch is merged into the original branch using a three-way merge
If conflicts exist, they should be detected and surfaced to the user
The PlanApplyService.handle_merge_failure() should be called with conflict details

Actual Behavior

GitWorktreeSandbox.commit() (lines 433–438) runs:

_run_git(
    ["merge", self._branch_name, "--no-edit"],
    cwd=self._original_path,
    timeout=self._git_timeout,
)

Problem 1: --no-edit does not prevent merge conflicts

The --no-edit flag only suppresses the merge commit message editor. It does NOT prevent merge conflicts. When git merge encounters conflicts, it returns a non-zero exit code and leaves conflict markers in the files.

Since _run_git() uses check=True, a merge conflict will raise subprocess.CalledProcessError, which is caught and re-raised as SandboxCommitError (lines 447–452):

except subprocess.CalledProcessError as exc:
    self._pre_merge_commit = None
    self._status = SandboxStatus.ERRORED
    raise SandboxCommitError(
        f"Failed to commit sandbox {self._sandbox_id}: {exc.stderr.strip()}"
    ) from exc

Problem 2: Conflict details are lost

When a merge conflict occurs, git merge outputs the conflicting files to stderr. The SandboxCommitError message includes exc.stderr.strip(), but:

The stderr from git merge on conflict is typically just "Automatic merge failed; fix conflicts and then commit the result."
The actual conflicting file paths are in stdout (e.g., CONFLICT (content): Merge conflict in src/auth/session.py)
The _run_git() function captures both stdout and stderr, but only exc.stderr is included in the error message — the stdout with conflict file paths is discarded

Problem 3: Repository left in conflicted state

When git merge fails with conflicts, the repository is left in a mid-merge state (.git/MERGE_HEAD exists). The SandboxCommitError is raised, but there is no cleanup of the merge state. The rollback() method uses git reset --hard which would clean this up, but it's not called automatically on SandboxCommitError.

Problem 4: PlanApplyService.handle_merge_failure() is never called

PlanApplyService.handle_merge_failure() exists (lines 396–435) and is designed to handle this case, but it is never called from the apply path. The SandboxCommitError propagates up but is not caught and routed to handle_merge_failure().

Code Locations

Merge command: src/cleveragents/infrastructure/sandbox/git_worktree.py, commit() (lines 433–438)
Error handling: src/cleveragents/infrastructure/sandbox/git_worktree.py, lines 447–452
Merge failure handler: src/cleveragents/application/services/plan_apply_service.py, handle_merge_failure() (line 396)
Missing integration: No caller connects SandboxCommitError to handle_merge_failure()

Steps to Reproduce

Create a plan that modifies a file
Manually modify the same lines in the original repository (simulating concurrent changes)
Execute and apply the plan
Observe: Plan enters ERRORED state with a generic "Failed to commit sandbox" message, no conflict file details, and the repository is left in a mid-merge state

Impact

Merge conflicts during apply produce an unhelpful error message
The conflicting file paths are not surfaced to the user
The repository may be left in a mid-merge state requiring manual git merge --abort
The PlanApplyService.handle_merge_failure() infrastructure is never used

Fix Required

In GitWorktreeSandbox.commit():

Capture stdout from the merge command (not just stderr) to extract conflicting file paths
On CalledProcessError, parse the stdout for CONFLICT lines to extract conflict details
Run git merge --abort to clean up the mid-merge state before raising SandboxCommitError
Include the conflicting file paths in the SandboxCommitError message

In the apply path (wherever commit_all() is eventually called — see issue #5444):

Catch SandboxCommitError and call PlanApplyService.handle_merge_failure() with the conflict details
Ensure the plan transitions to ERRORED with actionable conflict information

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Bug Report **Feature Area**: git-worktree-sandbox — `agents plan apply` merge conflict handling **Severity**: Priority/Critical — merge conflicts during apply are not properly handled; the plan may enter ERRORED state without actionable conflict information ## What Was Tested Code-level analysis of `GitWorktreeSandbox.commit()` in `src/cleveragents/infrastructure/sandbox/git_worktree.py` against the spec requirement for conflict detection and resolution. ## Expected Behavior (from spec) Per the specification, when `agents plan apply` is executed: 1. The sandbox branch is merged into the original branch using a three-way merge 2. If conflicts exist, they should be **detected** and **surfaced** to the user 3. The `PlanApplyService.handle_merge_failure()` should be called with conflict details ## Actual Behavior `GitWorktreeSandbox.commit()` (lines 433–438) runs: ```python _run_git( ["merge", self._branch_name, "--no-edit"], cwd=self._original_path, timeout=self._git_timeout, ) ``` **Problem 1: `--no-edit` does not prevent merge conflicts** The `--no-edit` flag only suppresses the merge commit message editor. It does NOT prevent merge conflicts. When `git merge` encounters conflicts, it returns a non-zero exit code and leaves conflict markers in the files. Since `_run_git()` uses `check=True`, a merge conflict will raise `subprocess.CalledProcessError`, which is caught and re-raised as `SandboxCommitError` (lines 447–452): ```python except subprocess.CalledProcessError as exc: self._pre_merge_commit = None self._status = SandboxStatus.ERRORED raise SandboxCommitError( f"Failed to commit sandbox {self._sandbox_id}: {exc.stderr.strip()}" ) from exc ``` **Problem 2: Conflict details are lost** When a merge conflict occurs, `git merge` outputs the conflicting files to stderr. The `SandboxCommitError` message includes `exc.stderr.strip()`, but: - The stderr from `git merge` on conflict is typically just "Automatic merge failed; fix conflicts and then commit the result." - The actual conflicting file paths are in stdout (e.g., `CONFLICT (content): Merge conflict in src/auth/session.py`) - The `_run_git()` function captures both stdout and stderr, but only `exc.stderr` is included in the error message — the stdout with conflict file paths is discarded **Problem 3: Repository left in conflicted state** When `git merge` fails with conflicts, the repository is left in a mid-merge state (`.git/MERGE_HEAD` exists). The `SandboxCommitError` is raised, but there is no cleanup of the merge state. The `rollback()` method uses `git reset --hard` which would clean this up, but it's not called automatically on `SandboxCommitError`. **Problem 4: `PlanApplyService.handle_merge_failure()` is never called** `PlanApplyService.handle_merge_failure()` exists (lines 396–435) and is designed to handle this case, but it is never called from the apply path. The `SandboxCommitError` propagates up but is not caught and routed to `handle_merge_failure()`. ## Code Locations - **Merge command**: `src/cleveragents/infrastructure/sandbox/git_worktree.py`, `commit()` (lines 433–438) - **Error handling**: `src/cleveragents/infrastructure/sandbox/git_worktree.py`, lines 447–452 - **Merge failure handler**: `src/cleveragents/application/services/plan_apply_service.py`, `handle_merge_failure()` (line 396) - **Missing integration**: No caller connects `SandboxCommitError` to `handle_merge_failure()` ## Steps to Reproduce 1. Create a plan that modifies a file 2. Manually modify the same lines in the original repository (simulating concurrent changes) 3. Execute and apply the plan 4. Observe: Plan enters ERRORED state with a generic "Failed to commit sandbox" message, no conflict file details, and the repository is left in a mid-merge state ## Impact - Merge conflicts during apply produce an unhelpful error message - The conflicting file paths are not surfaced to the user - The repository may be left in a mid-merge state requiring manual `git merge --abort` - The `PlanApplyService.handle_merge_failure()` infrastructure is never used ## Fix Required In `GitWorktreeSandbox.commit()`: 1. Capture stdout from the merge command (not just stderr) to extract conflicting file paths 2. On `CalledProcessError`, parse the stdout for `CONFLICT` lines to extract conflict details 3. Run `git merge --abort` to clean up the mid-merge state before raising `SandboxCommitError` 4. Include the conflicting file paths in the `SandboxCommitError` message In the apply path (wherever `commit_all()` is eventually called — see issue #5444): 1. Catch `SandboxCommitError` and call `PlanApplyService.handle_merge_failure()` with the conflict details 2. Ensure the plan transitions to ERRORED with actionable conflict information --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 06:58:30 +00:00

HAL9000 commented

2026-04-09 07:07:50 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: Critical — GitWorktreeSandbox.commit() uses git merge --no-edit which silently fails on merge conflicts. Conflict details are not surfaced to PlanApplyService, meaning the apply phase can silently produce incorrect output when conflicts exist.
Milestone: v3.2.0 — sandbox commit is part of the plan apply flow
Story Points: 3 — M — requires replacing git merge --no-edit with proper conflict detection and error surfacing
MoSCoW: Must Have — silent merge failures in the apply phase can corrupt the target repository. This is a data integrity issue.
Parent Epic: Needs linking to the sandbox/apply epic

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Verified - **Priority**: Critical — `GitWorktreeSandbox.commit()` uses `git merge --no-edit` which silently fails on merge conflicts. Conflict details are not surfaced to `PlanApplyService`, meaning the apply phase can silently produce incorrect output when conflicts exist. - **Milestone**: v3.2.0 — sandbox commit is part of the plan apply flow - **Story Points**: 3 — M — requires replacing `git merge --no-edit` with proper conflict detection and error surfacing - **MoSCoW**: Must Have — silent merge failures in the apply phase can corrupt the target repository. This is a data integrity issue. - **Parent Epic**: Needs linking to the sandbox/apply epic --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 added

and removed

labels

2026-04-09 07:08:50 +00:00

HAL9000 referenced this issue