What causes "The model returned no resolution for the conflicted file "{}"" in gitbutlerapp/gitbutler?

The built-in retry may produce complete coverage; check whether the first attempt was truncated (token limit) and if so lower concurrency or raise max output tokens

gitbutlerapp/gitbutler · error · anyhow::Error

The model returned no resolution for the conflicted file "{}

Error message

The model returned no resolution for the conflicted file "{}"

What it means

The AI full-resolve path requires full coverage: after processing every returned resolution, each conflicted file must have an entry. The first file with no resolution (its slot still None) fails validation with this message - a partial answer cannot be spliced into the 'fully resolved commit' promise, unlike the per-hunk API which permits subsets.

Source

Thrown at crates/but-api/src/resolve/mod.rs:661

            apply::ensure_no_markers(&hunk.resolved_content, &file.path)?;
            picks[index].insert(
                hunk_index,
                apply::HunkPick::Content(hunk.resolved_content.clone()),
            );
        }
        resolved_files[index] = Some(ResolvedFile {
            path: file.path.clone(),
            hunks: resolution
                .hunks
                .iter()
                .map(|hunk| hunk.resolved_content.clone())
                .collect(),
            reasoning: resolution.reasoning.clone(),
        });
    }

    if let Some(missing) = resolved_files.iter().position(Option::is_none) {
        bail!(
            "The model returned no resolution for the conflicted file \"{}\"",
            request.files[missing].path
        );
    }

    Ok((picks, resolved_files.into_iter().flatten().collect()))
}

/// Record an undo point, apply `picks`, and commit the snapshot on success.
fn apply_with_snapshot(
    ctx: &mut but_ctx::Context,
    request: &ResolutionRequest,
    picks: &apply::PicksPerFile,
    operation: OperationKind,
    dry_run: DryRun,
    perm: &mut RepoExclusive,
) -> anyhow::Result<apply::AppliedResolution> {
    let maybe_oplog_entry = but_oplog::UnmaterializedOplogSnapshot::from_details_with_perm(

View on GitHub (pinned to caf1f223d3)

Solutions

The built-in retry may produce complete coverage; check whether the first attempt was truncated (token limit) and if so lower concurrency or raise max output tokens
Switch to a model with larger output capacity for commits with many conflicted files
Fall back to resolve_commit_conflict_hunks for the covered files and handle stragglers individually

Defensive patterns

Strategy: retry

Try / catch

try {
  await api.resolveCommitConflictsAi(commitId);
} catch (err) {
  if (String(err).includes('no resolution for the conflicted file')) {
    // likely token-limit truncation: retry once, then split work
    await api.resolveCommitConflictsAi(commitId);
  } else throw err;
}

Prevention

Raise the model's max output tokens or split very conflicted commits before AI resolving
Prefer per-hunk resolve for large conflict sets - it tolerates partial coverage by design
When injecting resolvers, iterate request.files exactly so no file is skipped

When it happens

Trigger: The model resolves most files but silently skips one - typically a large file hitting output-token limits, or a file whose conflicts the model deemed trivial and omitted. Any missing file aborts before any write.

Common situations: Output truncation on big conflict sets (token cap reached mid-JSON, though malformed JSON usually fails earlier); models summarizing instead of enumerating; injection-based resolvers (resolve_commit_conflicts_with) that forget a file.

Related errors

AI-assisted analysis of gitbutlerapp/gitbutler@caf1f223d3 (2026-08-20). Data as JSON: /api/errors/518d7ec0276d5829. Report an issue: GitHub.