zed-industries/zed · error

Fatal error: {:?}

Error message

Fatal error: {:?}

What it means

The command's async body produces an `anyhow::Result`; when it completes with Err, the CLI panics with 'Fatal error: {:?}' wrapping the error. The panic itself carries no new information — it is the terminal surfacing of an earlier operational failure (I/O, provider request, parsing) whose real cause is printed inside the panic message.

Source

Thrown at crates/edit_prediction_cli/src/main.rs:1583

                        let examples = finished_examples.lock().unwrap();
                        repair::print_report(&examples, args.confidence_threshold);
                    }
                    _ => (),
                };

                // For --in-place, atomically rename temp file to original
                if let Some(temp_path) = &in_place_temp_path {
                    let final_path = output.as_ref().expect("in_place_temp_path requires output");
                    std::fs::rename(temp_path, final_path)
                        .expect("Failed to rename temp file to final output");
                }

                anyhow::Ok(())
            }
            .await;

            if let Err(e) = result {
                panic!("Fatal error: {:?}", e);
            }

            let _ = cx.update(|cx| cx.quit());
        })
        .detach();
    });
}

fn rewrite_output(
    examples: &[Example],
    output_path: Option<&PathBuf>,
    markdown: bool,
) -> anyhow::Result<()> {
    if markdown {
        let dir = output_path.context("--markdown requires -o")?;
        for example in examples {
            let filename = format!("{}.md", example.spec.filename());
            let path = dir.join(&filename);

View on GitHub (pinned to f4178619ac)

Solutions

  1. Read the wrapped error in the panic payload — it names the actual failing operation
  2. Fix that underlying cause (correct path, credentials, connectivity, disk space)
  3. Re-run the command; use --fresh only if stale intermediate state is implicated
Defensive patterns

Strategy: validation

Validate before calling

// shell: sanity-check inputs before the (long) run
for f in "${INPUTS[@]}"; do test -e "$f" || { echo "missing input: $f"; exit 1; }; done

Try / catch

try {
    command.run()
} catch (err) {
    // panic payload 'Fatal error: {:?}' wraps the anyhow chain;
    // log err.cause chain and retry only transient causes (network)
    report(err.cause ?? err);
}

Prevention

When it happens

Trigger: Any failure inside the command's run loop: unreadable input paths, provider/network errors while fetching predictions or context, malformed example files, or failures writing the output file.

Common situations: Invalid --inputs path, expired tokens or provider outages mid-run, disk full when writing results, or network interruption while cloning/fetching repos.

Related errors


AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20). Data as JSON: /api/errors/3b917946bb322629. Report an issue: GitHub.