Pipe reader is not woken on writer close: every `|` stage stalls for `maxBlockingReadMs` at EOF, then fails with `EAGAIN`

[pdparchitect]

In a guest shell pipeline, a WebAssembly command reading from a pipe is not woken when the writer exits. The reader blocks until the runtime's limits.resources.maxBlockingReadMs cap (10s by default) expires, and then either completes or fails with Would block / Resource temporarily unavailable (EAGAIN). In my tests a three-stage pipeline pays the cap once per stage.

Single commands are unaffected (~100ms). The stall happens only when the writer finishes before the reader has consumed everything.

Environment

• @rivet-dev/agentos-core 0.2.19 (@rivet-dev/agentos-sidecar-linux-x64-gnu 0.2.19)
• Node.js v24.20.0
• Linux x86_64, glibc (Debian bookworm, node:24.20.0-bookworm-slim image)

Reproduction

mkdir agentos-pipe && cd agentos-pipe && npm init -y >/dev/null
npm i @rivet-dev/agentos-core@0.2.19

// repro.mjs
import { AgentOs } from "@rivet-dev/agentos-core";

const permissions = { fs: "allow", childProcess: "allow", process: "allow", env: "allow", binding: "allow", network: "allow" };

for (const maxBlockingReadMs of [undefined, 2000, 500]) {
  const vm = await AgentOs.create({
    permissions,
    ...(maxBlockingReadMs ? { limits: { resources: { maxBlockingReadMs } } } : {}),
  });

  const run = async (label, cmd) => {
    const t = Date.now();
    const r = await vm.process.exec(cmd, { cwd: "/workspace", output: { capture: "all" }, timeoutMs: 60_000 });
    console.log(`limit=${maxBlockingReadMs ?? "default"}`.padEnd(14), label.padEnd(22), `${Date.now() - t}ms`, `rc=${r.exitCode}`, JSON.stringify(r.stderr.slice(0, 50)));
  };

  await run("single command", "echo hi");
  await run("ls | sed", "ls -la / | sed -n '1,3p'");
  await run("env | sort | sed", "env | sort | sed -n '1,2p'");
  await run("node | cat", "node -e 'setTimeout(() => console.log(\"n\"), 1500)' | cat");
  await run("(sleep 3; echo) | cat", "(sleep 3; echo late) | cat");

  await vm.dispose();
}
process.exit(0);

node repro.mjs

Measured

maxBlockingReadMs	command	time	exit	stderr
default (10000)	echo hi	94ms	0
default	ls -la / | sed -n '1,3p'	650ms	0
default	env | sort | sed -n '1,2p'	30268ms	1	sed: Would block
default	node -e '...' | cat	10168ms	0
default	(sleep 3; echo late) | cat	3224ms	0
2000	env | sort | sed -n '1,2p'	332ms	0
2000	node -e '...' | cat	2185ms	1	cat: -: Resource temporarily unavailable (output lost)
500	env | sort | sed -n '1,2p'	838ms	1	sed: Would block
500	node -e '...' | cat	1659ms	1	cat: -: Resource temporarily unavailable (output lost)

A realistic agent-authored diagnostic script with five pipelines
(ls -la | sed -n '1,100p', bash --version | head -n 1,
env | sort | sed -E ... | sed -n '1,250p', ...) took 50.8s end to end;
the same script without pipes completes in well under a second.

Expected

The reader receives end-of-file as soon as the last writer closes its end, and a pipeline of fast commands completes in milliseconds regardless of maxBlockingReadMs. EAGAIN should never reach a program reading a blocking pipe.

Actual

The reader is only woken by new data, not by the writer closing, so it sits out the full maxBlockingReadMs at end of stream - once per stage - and then observes EAGAIN. Lowering the limit shortens the stall but turns it into data loss for any producer that is quiet longer than the limit (node | cat above), so there is no safe workaround from the caller's side.

Notes

• The timing matters: pipelines whose writer finishes before the reader drains (env, sort, node -e) stall; (sleep 3; echo) | cat, where the reader is already blocked in read when the writer closes, does not. That suggests the hangup/EOF wake-up is delivered only to a reader already parked in a blocking read, not to one that arrives afterwards.
• Possibly related: Interactive PTY: compound commands silently produce no output (WASI EFAULT), and shell diagnostics never reach the terminal #1893 (compound commands in PTY mode produce no output, WASI EFAULT).

[defiufo]

Spent some time reproducing this against main (65dc5e6). Short version: the kernel's pipe layer is not the bug — EOF-on-writer-close works correctly at every level I could test — but there is a real, separately-fixable defect in how the maxBlockingReadMs watchdog is reported, and it explains the Would block / lost-output half of your report. Sharing the evidence so whoever picks this up doesn't re-derive it.

What is NOT broken

I wrote throwaway tests directly against PipeManager and KernelVm. All of these pass on main:

Scenario	Result
Reader arrives after writer wrote and closed	EOF immediately
Reader already parked in blocking read when writer closes	woken, EOF
Drain N buffered chunks then EOF, writer already gone	EOF, no stall
Forked writer child closes its end and exits	EOF
Writer child exits without closing anything (env in env | sort)	EOF in 1.2µs
poll() on a read end with no writers	ready_count=1, revents=0x0010 (POLLHUP)

That last pair matters for your hypothesis. You suggested the hangup is delivered only to a reader already parked in a blocking read. That is not what the kernel does — PipeManager::close drains waiting_reads and sets their result to None, and a reader arriving later re-checks writers == 0 before parking, and poll reports POLLHUP unconditionally for a writerless read end. Process teardown (cleanup_process_resources) reclaims inherited fds correctly too, so a child that just exits still releases its write end.

So the stall is a retained write-end reference above the kernel, not a missed wakeup inside it. I reproduced the exact symptom by deliberately holding a write fd open:

retained-writer read -> Err(KernelError { code: "EAGAIN", message: "pipe read timed out" }) after 300ms

That is your sed: Would block, exactly. Something in the pipeline construction path is keeping a writer alive for the reader's whole stall. Candidates I'd look at, in order: preapply_posix_spawn_file_actions / install_preapplied_posix_spawn_file_actions (crates/native-sidecar/src/execution/child_process.rs:2429), which stages fds through a temporary process and fd_transfers them — each install_transferred_at does increment_ref_count, so a staged-but-unclosed write end would pin writers > 0 — and install_kernel_stdin_pipe (execution/stdio.rs:414), which already carries a comment about exactly this failure mode and sets FD_CLOEXEC to avoid it.

I could not get a WASM guest running in my sandbox to confirm which one, so I'm stopping short of naming a culprit.

What IS broken, and is fixable today

Independent of the leak: the watchdog reports EAGAIN on descriptors that are not O_NONBLOCK.

kernel.rs:4976 collapses three distinct cases into one timeout:

if (entry.description.flags() | entry.status_flags) & O_NONBLOCK != 0 {
    Some(Duration::ZERO)          // 1. nonblocking: EAGAIN is correct
} else {
    timeout.or_else(|| self.blocking_read_timeout())  // 2. caller timeout  3. internal watchdog
}

Case 3 is an internal watchdog on a blocking fd. POSIX reserves EAGAIN for O_NONBLOCK, so a guest reading a blocking pipe has no way to interpret it — sed prints Would block and dies, cat prints Resource temporarily unavailable and loses buffered output. That's why lowering maxBlockingReadMs converts your stall into data loss: it isn't a tuning tradeoff, it's a contract violation that gets more likely as the cap shrinks.

This is why there's no safe caller-side workaround, which I think is the most important thing in your report.

Failing test against main (passes with a patch that returns an empty retryable read instead):

config.resources.max_blocking_read_ms = Some(150);
let (read_fd, _write_fd) = k.open_pipe("shell", pid).unwrap(); // writer retained, idle
let err = k.fd_read_with_timeout_result("shell", pid, read_fd, 1024, None).unwrap_err();
assert_ne!(err.code(), "EAGAIN"); // fails on main

The catch, for whoever fixes this

crates/kernel/tests/resource_accounting.rs:1449 (blocking_pipe_and_pty_reads_time_out_instead_of_hanging_forever) asserts EAGAIN for precisely this case, for both pipes and PTYs. So the current behavior is deliberate, not an oversight, and my patch breaks that test.

That makes this a design question rather than a one-line fix, and it needs a maintainer's call:

1. Keep the watchdog but give it a distinct code (ETIMEDOUT), and teach the WASI layer to retry rather than surface it. Still breaks the existing assertion, but honestly.
2. Return a short/empty read on watchdog expiry, so a blocking reader loops instead of failing. What I prototyped; also breaks the assertion.
3. Leave the kernel alone and fix only the fd leak. The stall disappears, the watchdog stops firing in practice, and the latent EAGAIN contract bug stays for the next person.

I'd argue against 3 alone: the watchdog is a backstop, and a backstop that corrupts output when it fires is worth fixing on its own terms.

I have the repro tests and the prototype patch and am happy to open a PR against whichever direction a maintainer prefers — but I didn't want to push a change that knowingly rewrites an intentional assertion without that call being made first.

Note the same EAGAIN-on-blocking-fd pattern exists for PTYs (kernel.rs:4990) and sockets (kernel.rs:4951), so whatever is decided should probably cover all three.