What causes "failed to flush json errors" in facebook/flow?

Capture to a file first and probe the file: `flow check-contents file.js --json > r.json && grep -q . r.json`

failed to flush json errors

Error message

failed to flush json errors

What it means

The out.flush() immediately after the JSON error report in check-contents pushes buffered stdout bytes toward the reader. Buffered writes can appear to succeed while the reader is already gone, so EPIPE (pipe reader exited) or ENOSPC (redirect target full) often first surfaces at this flush; the .expect() then panics with 'failed to flush json errors' even though the preceding write call returned Ok.

Source

Thrown at rust_port/crates/flow_cli/src/check_contents_command.rs:146

            let strip_root = strip_root
                .as_deref()
                .map(|root| root.to_string_lossy().into_owned());
            let stdout = std::io::stdout();
            let mut out = stdout.lock();
            flow_common_errors::error_utils::json_output::print_errors_with_offset_kind(
                &mut out,
                strip_root.as_deref(),
                suppressed_errors,
                pretty,
                json_version
                    .unwrap_or(flow_common_errors::error_utils::json_output::JsonVersion::JsonV1),
                &stdin_file,
                offset_kind,
                errors,
                warnings,
            )
            .expect("failed to write json errors");
            out.flush().expect("failed to flush json errors");
        };
    match response {
        server_prot::response::StatusResponse::ERRORS {
            errors,
            warnings,
            suppressed_errors,
        } => {
            if json {
                print_json(&errors, &warnings, &suppressed_errors)
            } else {
                let stdout = std::io::stdout();
                let mut out = stdout.lock();
                flow_common_errors::error_utils::cli_output::print_errors(
                    &mut out,
                    &error_flags,
                    &stdin_file,
                    strip_root.as_deref(),
                    &errors,

View on GitHub (pinned to f88ac94bcf)

Solutions

Capture to a file first and probe the file: `flow check-contents file.js --json > r.json && grep -q . r.json`
Insert a buffering stage (`| cat`) or remove the early-exiting consumer
Free disk space or fix the redirect target if flushing to a full filesystem
Maintainer: treat ErrorKind::BrokenPipe on the flush as a silent exit(141), not a panic

Example fix

// before
out.flush().expect("failed to flush json errors");

// after
if let Err(e) = out.flush() {
    if e.kind() == std::io::ErrorKind::BrokenPipe {
        std::process::exit(141);
    }
    panic!("failed to flush json errors: {e}");
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Probing success? Use the exit code instead of probing the stream:
// flow check-contents file.js --json > report.json
// then inspect report.json — no live pipe to break.

Try / catch

if let Err(e) = out.flush() {
    if e.kind() == std::io::ErrorKind::BrokenPipe {
        std::process::exit(141);
    }
    panic!("failed to flush json errors: {e}");
}

Prevention

Replace `cmd | grep -q ...` probes with capture-to-file plus exit-code checks
Keep pipe consumers alive until EOF, or add a `| cat` buffering stage
Check disk space before producing large JSON reports on constrained runners

When it happens

Trigger: `flow check-contents file.js --json | grep -q .` — grep exits after matching, then the final flush hits EPIPE; redirecting to a filesystem that fills up mid-report; any consumer that closes the pipe between the last write and the flush.

Common situations: Shell scripts using grep -q/head as a success probe on JSON output; log rotation closing a file being written; CI uploading artifacts while the job still writes output.

Related errors

AI-assisted analysis of facebook/flow@f88ac94bcf (2026-08-20). Data as JSON: /api/errors/a5b4e91c6fea614c. Report an issue: GitHub.