Y2Z/monolith · critical

could not write output

Error message

could not write output

What it means

This panic comes from `output.write(&result).expect("could not write output")` in main.rs:286 (the STDIN-pipe branch). `Output::write` propagates `io::Error` from `write_all`/`flush` on either stdout or the destination file. The output object was created successfully, but writing/flushing the rendered monolithic document bytes failed, so the program panics after all fetching work has already completed.

Source

Thrown at src/main.rs:286

    let session: Session = Session::new(cache, cookies, options);

    // Retrieve target from source and output result
    if cli.target == "-" {
        // Read input from pipe (STDIN)
        let data: Vec<u8> = read_stdin();

        match create_monolithic_document_from_data(session, data, None, None) {
            Ok((result, title)) => {
                // Define output
                let mut output = Output::new(
                    &destination.unwrap_or(String::new()),
                    &title.unwrap_or_default(),
                    output_format,
                )
                .expect("could not prepare output");

                // Write result into STDOUT or file
                output.write(&result).expect("could not write output");
            }
            Err(error) => {
                if !silent {
                    print_error_message(&format!("Error: {}", error));
                }

                exit_code = 1;
            }
        }
    } else {
        match create_monolithic_document(session, cli.target) {
            Ok((result, title)) => {
                // Define output
                let mut output = Output::new(
                    &destination.unwrap_or(String::new()),
                    &title.unwrap_or_default(),
                    output_format,
                )

View on GitHub (pinned to a6fc8d0095)

Solutions

  1. Check free disk space and write quota on the destination volume.
  2. Avoid piping output into commands that close early (`head`); use `monolith - > file.html` or capture to a file first.
  3. Verify the destination file/mount is writable and not locked by another process.
  4. Re-run without piping stdout; if the panic was EPIPE on stdout, redirect to a file.
  5. For automation, wrap the call so a panic exit (code 101) is detected and retried or reported.

Example fix

// before (shell)
monolith - -o page.html | head -c 100   # closes pipe -> "could not write output" panic

// after (shell)
monolith - -o page.html   # write fully to file, no truncated pipe consumer
Defensive patterns

Strategy: try-catch

Validate before calling

#!/usr/bin/env bash
df -h . | awk 'NR==2 {exit ($5+0 > 95 ? 1 : 0)}' || { echo "disk nearly full"; exit 1; }
monolith - -o page.html || code=$?
[ "$code" = "101" ] && echo "output write panicked (disk/pipe?)"

Try / catch

match std::panic::catch_unwind(|| {
    output.write(&result)
}) {
    Ok(Ok(())) => {},
    Ok(Err(e)) => eprintln!("write failed: {}", e),
    Err(_) => eprintln!("panicked while writing output (disk full or closed pipe?)"),
}

Prevention

When it happens

Trigger: The destination file became unwritable after creation (disk full mid-write, quota exceeded, permission revoked), or writing to stdout failed because the pipe was closed early (e.g. `monolith - | head -n 1` causing SIGPIPE/EPIPE) or stdout redirected to a full/unwritable target.

Common situations: Disk filled up while saving a very large page; output piped into `head`, `less -F`, or a process that exits early, closing the pipe; NFS/network mounts dropping mid-write; tmpfs quota exceeded; antivirus or backup software locking the file on Windows.

Related errors


AI-assisted analysis of Y2Z/monolith@a6fc8d0095 (2026-09-05). Data as JSON: /api/errors/74386054a1423203. Report an issue: GitHub.