pbakaus/impeccable · error

{}

Error message

{}

What it means

In the critique-storage `write` flow, reading the body file with `std::fs::read` can fail; on failure the code builds a Node-style 'uncaught exception' message via `uncaught(&node_read_error(body_file, &e))` — mirroring the original JS behavior of a stack trace on stderr — and prints it through this `{}` wrapper with exit 1. The visible text is the formatted read error (e.g. ENOENT for the body file).

Source

Thrown at crates/context/src/critique_storage.rs:472

                None => {
                    io.err("no stable slug for input\n");
                    1
                }
            }
        }
        "write" => {
            let slug_arg = rest.first().map(String::as_str).unwrap_or("");
            let slug = coerce_slug(rest.first().map(String::as_str), &cwd);
            let body_file = rest.get(1).filter(|s| !s.is_empty());
            let (Some(slug), Some(body_file)) = (slug, body_file) else {
                io.err("usage: write <slug-or-target> <body-file>\n");
                return 1;
            };
            let raw = match std::fs::read(body_file) {
                Ok(b) => String::from_utf8_lossy(&b).into_owned(),
                Err(e) => {
                    // JS: uncaught exception -> stack trace on stderr, exit 1
                    io.err(&format!("{}\n", uncaught(&node_read_error(body_file, &e))));
                    return 1;
                }
            };
            let mut parsed_meta: Map<String, Value> = Map::new();
            if let Some(m) = env.get("IMPECCABLE_CRITIQUE_META").filter(|s| !s.is_empty()) {
                if let Ok(Value::Object(o)) = serde_json::from_str::<Value>(m) {
                    parsed_meta = o;
                }
            }
            // JS #660: the helper, not caller metadata, owns the target
            // fingerprint/identity. Drop any caller-supplied copies (preserving
            // the order of the rest) and append the freshly resolved values.
            let mut meta: Map<String, Value> = Map::new();
            for (k, v) in parsed_meta {
                if k != "target_fingerprint" && k != "target_path" && k != "target_identity" {
                    meta.insert(k, v);
                }
            }

View on GitHub (pinned to 2bc2879276)

Solutions

  1. Verify the body-file path exists and is readable before invoking (`test -r <file>`).
  2. Pass an absolute path, or run from the directory where the body file was created.
  3. Create the body file first if your pipeline assumes it exists.
  4. Check file permissions if the path exists but the process user can't read it.

Example fix

// before
context critique write my-app-web ./kritique.md
// uncaught: ENOENT ... kritique.md
// after
context critique write my-app-web ./critique.md
Defensive patterns

Strategy: validation

Validate before calling

import { accessSync, constants } from 'node:fs';
try {
  accessSync(bodyFile, constants.R_OK);
} catch {
  throw new Error(`body file not readable: ${bodyFile}`);
}

Type guard

function bodyFileReadable(p) {
  try { accessSync(p, constants.R_OK); return true; } catch { return false; }
}

Try / catch

try {
  const body = readFileSync(bodyFile, 'utf8');
} catch (e) {
  // mirror of the CLI's node_read_error: ENOENT vs EACCES vs EISDIR
  console.error(`Cannot read ${bodyFile}: ${e.code ?? e.message}`);
  process.exit(1);
}

Prevention

When it happens

Trigger: Calling `write <slug> <body-file>` where body-file doesn't exist, is a directory, or isn't readable due to permissions; the path was computed relative to a different cwd than the one the CLI runs in; a variable interpolated an empty/incorrect path that slipped past the emptiness check.

Common situations: Typoed body-file path; generating the body file in a temp dir that was cleaned before write; running the CLI from a different directory than the script that created the file; permission-restricted critique directories.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors


AI-assisted analysis of pbakaus/impeccable@2bc2879276 (2026-09-08). Data as JSON: /api/errors/0792201b10ea39a9. Report an issue: GitHub.