wasip2 CLI stdio discards host `io::Error` kind, surfaces EIO instead of EPIPE/EISDIR

[eduardomourar]

Test Case

No wasm file needed — reproducible with any wasip2 guest that writes past a closed pipe, or reads stdin redirected from a directory. Minimal repro source: [gist-equivalent below].

// write side
use std::io::Write;
fn main() {
    loop {
        if let Err(e) = std::io::stdout().write_all(b"0123456789\n") {
            eprintln!("write error: kind={:?} raw_os_error={:?}", e.kind(), e.raw_os_error());
            return;
        }
    }
}

// read side
use std::io::Read;
fn main() {
    let mut buf = [0u8; 16];
    match std::io::stdin().read(&mut buf) {
        Err(e) => eprintln!("stdin read error: kind={:?} raw_os_error={:?}", e.kind(), e.raw_os_error()),
        _ => {}
    }
}

Steps to Reproduce

• Compile the write-side repro for wasm32-wasip2, run under wasmtime run pipe.wasm | head -c 30, so the reader closes early.
• Compile the read-side repro for wasm32-wasip2, run under wasmtime run --dir <dir> stdin.wasm < <dir>, redirecting stdin from a directory.
• Compare against the same repros compiled for wasm32-wasip1.

Expected Results

wasip1 correctly reports BrokenPipe/EPIPE(64) for the write case and IsADirectory/EISDIR(31) for the read case — matching native Unix.

Actual Results

wasip2 reports InputOutputError/EIO(29) for both cases. Confirmed on wasmtime 45.0.0 and 47.0.3 (latest release, 2026-07-31) — unchanged between versions.

Root cause (traced through wasi-libc + wasmtime source):

• crates/wasi/src/cli/stdout.rs#StdioOutputStream::write/flush wraps any error from std::io::stdout().write_all() as StreamError::LastOperationFailed(anyhow::Error) via wasmtime::format_err!(e), even when e.kind() == BrokenPipe. It never returns StreamError::Closed.
• crates/wasi/src/cli/worker_thread_stdin.rs#WasiStdin::read does the same for StdinState::Error(e) => Err(StreamError::LastOperationFailed(e.into())), discarding e.kind() == IsADirectory.
• Downstream, wasi-libc's wasip2_handle_write_error/wasip2_handle_read_error only distinguish StreamError::Closed from LastOperationFailed, mapping the latter to a generic EIO — so once the specific error kind is erased above, it can't be recovered here either.
• wasip1 avoids this because From<StreamError> for types::Error downcasts LastOperationFailed's inner error back to std::io::Error and runs it through filesystem::ErrorCode::from, which has real RustixErrno::PIPE/ISDIR arms. The p2 CLI-stdio path has no equivalent recovery step.

This affects every wasip2 guest, not just Rust's — e.g. uutils/coreutils#13625 had to add a userland wasi_is_broken_pipe helper checking for raw errno 29 as a workaround.

Versions and Environment

Wasmtime version or commit: 45.0.0 and 47.0.3 (both exhibit the bug)

Operating system: macOS (Darwin), confirmed reproducible; likely platform-independent since the bug is in wasmtime's stdio glue rather than any OS-specific path

Architecture: aarch64 host, wasm32-wasip2 guest

Extra Info

The wasi:io/streams spec's stream-error type is designed for exactly this: it carries an opaque error resource that other interfaces can "downcast" into more specific info (e.g. wasi:filesystem/types/filesystem-error-code). A fix could either (a) have StdioOutputStream::write/WasiStdin::read check e.kind() and return StreamError::Closed for BrokenPipe (matching what wasi-libc already expects), or (b) give p2's CLI stdio the same io::Error-recovery path p1 already has via filesystem::ErrorCode::from.

[alexcrichton]

The behavior you're describing here is an artifact of WASI's interfaces as opposed to Wasmtime's implementation. If you're interested in having this resolved I'd recommend filing an issue in the upstream WASI specification repository.

[eduardomourar]

@alexcrichton, thanks for looking at this. I don't think this is a spec limitation, though. The stream-error type's two variants (last-operation-failed(error)/closed) are the full interface, sure, but wasmtime's own p1 path already handles this correctly: From<StreamError> for types::Error in p1.rs downcasts the inner error back to std::io::Error and maps it through filesystem::ErrorCode::from (which has real PIPE/ISDIR arms). p2's CLI-stdio path just doesn't do any equivalent recovery. It wraps everything as opaque LastOperationFailed in cli/stdout.rs and cli/worker_thread_stdin.rs, and wasi-libc maps that to EIO since it can only distinguish Closed from LastOperationFailed.

So the spec already accommodates the fix; it's just that the p2 implementation doesn't use the same trick p1 does. A minimal fix could be as simple as returning StreamError::Closed when e.kind() == BrokenPipe (which is what wasi-libc already expects on that variant), or giving p2 the same ErrorCode recovery p1 has.

Happy to put a PR together if either approach sounds reasonable.

[alexcrichton]

Ah sorry yeah I can expand on my previous message a bit. You're correct that in wasip1 and wasip2 there are vectors by which these precise errors can be communicated. My comment is that for wasip3, the latest iteration of WASI, there is no means by which to communicate precise errors via stdio right now. You can see the current specification here and notably what I'm referring to is this error type definition which can represent EPIPE but cannot represent EISDIR. I've tested locally for wasip3 and was able to get EPIPE correctly with the steps you outlined, but EISDIR showed up as EIO.

For wasip2, however, if you'd like then yeah having a PR to make the error type more precise I think would be fine to add to Wasmtime. I'll reopen for further discussion on that if needed, too.