nikivdev/code · error

resolver {} failed for {}: {}

Error message

resolver {} failed for {}: {}

What it means

After spawning a configured external resolver command, the tool checks the child's exit status. A non-zero exit bails with the resolver name, the candidate it ran against, and the resolver's stderr — or the exit status if stderr was empty. It surfaces external tool failures as a single diagnostic.

Source

Thrown at src/ai.rs:12585

        let command_text = render_reference_resolver_command(
            &resolver.command,
            candidate,
            query_text,
            target_path,
        );
        let args = shell_words::split(&command_text)
            .with_context(|| format!("invalid resolver command: {}", command_text))?;
        let Some((program, rest)) = args.split_first() else {
            bail!("empty resolver command for {}", resolver.name);
        };
        let output = Command::new(program)
            .args(rest)
            .current_dir(target_path)
            .output()
            .with_context(|| format!("failed to run resolver {}", resolver.name))?;
        if !output.status.success() {
            let stderr = String::from_utf8_lossy(&output.stderr).trim().to_string();
            bail!(
                "resolver {} failed for {}: {}",
                resolver.name,
                candidate,
                if stderr.is_empty() {
                    format!("exit status {}", output.status)
                } else {
                    stderr
                }
            );
        }
        let stdout = String::from_utf8_lossy(&output.stdout).trim().to_string();
        if stdout.is_empty() {
            bail!(
                "resolver {} returned empty output for {}",
                resolver.name,
                candidate
            );
        }

View on GitHub (pinned to a747e741ae)

Solutions

  1. Run the resolver command manually for that candidate to see the real failure
  2. Install or fix the resolver program/dependencies it depends on
  3. Make the resolver script tolerate no-selection (exit 0) or handle the failure case
  4. Check PATH/env inside the spawned command's context

Example fix

// before (resolver script ends with)
fzf  # aborting fzf exits non-zero
// after
sel=$(fzf) || exit 0
echo "$sel"
Defensive patterns

Strategy: try-catch

Validate before calling

let status = Command::new(&program).args(&rest).current_dir(&target).status()?;
if !status.success() {
    eprintln!("resolver '{}' would fail ({}), skipping", resolver.name, status);
}

Type guard

fn resolver_runs(name: &str, program: &str, rest: &[String], dir: &Path) -> bool {
    Command::new(program).args(rest).current_dir(dir).status().map(|s| s.success()).unwrap_or(false)
}

Try / catch

match result {
    Err(e) if e.to_string().contains("failed for") => {
        eprintln!("resolver failed; falling back to default selection");
        default_selection()
    }
    other => other,
}

Prevention

When it happens

Trigger: The resolver program exits non-zero for a candidate: script bug, missing dependency inside the script, fzf canceled with Esc/Ctrl-C (exit 130), or the command requires a TTY/inputs it didn't get.

Common situations: fzf/interactive pickers aborted by the user; resolver scripts failing because HOME/cache/env differs; resolver not installed in PATH for the subprocess environment.

Related errors


AI-assisted analysis of nikivdev/code@a747e741ae (2026-09-01). Data as JSON: /api/errors/bb224e733a2ae2c0. Report an issue: GitHub.