nikivdev/code · error

{}

Error message

{}

What it means

Generic jj command failure error in src/sync.rs: after the index-lock special case, any remaining `jj git export` failure (or any other jj failure propagated from jj_run_output_in) is bailed as `bail!("{}", failure)` where `failure` is jj_failure_message(args, output). The message content is whatever the jj binary reported, so its meaning depends on the underlying jj command.

Source

Thrown at src/sync.rs:4650

                max_retries,
                delay.as_millis()
            );
            std::thread::sleep(delay);
            continue;
        }

        jj_print_output(&output);
        let failure = jj_failure_message(&args, &output);
        if is_git_index_lock_error(&failure_text) {
            let retries = JJ_GIT_EXPORT_LOCK_RETRY_DELAYS_MS.len();
            bail!(
                "{}. Git index stayed locked after {} retr{}; close competing git/jj processes or remove stale .git/index.lock, then retry.",
                failure,
                retries,
                if retries == 1 { "y" } else { "ies" }
            );
        }
        bail!("{}", failure);
    }

    unreachable!("jj git export retry loop should always return");
}

fn jj_run_in(repo_root: &Path, args: &[&str]) -> Result<()> {
    let output = jj_run_output_in(repo_root, args)?;
    jj_print_output(&output);
    if !output.status.success() {
        bail!("{}", jj_failure_message(args, &output));
    }
    Ok(())
}

fn jj_preferred_binary() -> std::path::PathBuf {
    if let Ok(path) = std::env::var("FLOW_JJ_BIN") {
        let candidate = PathBuf::from(path);
        if candidate.exists() {

View on GitHub (pinned to a747e741ae)

Solutions

  1. Read the embedded `failure` text in the message to identify the jj error
  2. Run the same jj command manually (from the message context) to reproduce and inspect full output
  3. Check jj version and repo state (`jj st`, `jj log`) for corruption or unnormalized state
  4. Fix the underlying cause (rebase conflicting change, fix config, authenticate) and re-run sync
Defensive patterns

Strategy: try-catch

Validate before calling

// verify jj works before invoking sync
let out = std::process::Command::new(jj_bin()).arg("--version").output()?;
if !out.status.success() {
    eprintln!("jj binary is not functional; fix FLOW_JJ_BIN or install jj");
}

Try / catch

match sync_result {
    Err(e) => {
        // message body is jj's own failure text
        eprintln!("jj failure: {e}; run the same jj command manually for full output");
    }
    ok => ok?,
}

Prevention

When it happens

Trigger: Any jj command invoked by the sync machinery (e.g. `jj git export` outside the lock path) exits with non-zero status; jj_failure_message's text becomes the whole error message.

Common situations: Invalid jj workspace/repo state; jj version mismatch; malformed arguments constructed by the sync code; jj not authenticated for git push/pull operations.

Related errors


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