fix: bound workspace upload by an idle-progress timeout so a dead peer errors instead of hanging - #892

Fixes #886
Routing-Key: inbox-route/I_kwDOSUhdos8AAAABJr7f3g

Problem

A workspace upload streams a tar into the daemon's SSH channel via stream_tar_zstd in crates/minimal/src/file_upload.rs, using tokio::io::copy with no deadline anywhere in the path. The writer is a russh ChannelTx, which parks on SSH window availability. When the guest-side vsock connection is reset mid-transfer, the peer never sends the window adjustment that would wake the writer, so the write blocks with no waker and the client hangs indefinitely on Uploading project files... — observed at 75 s to 13 min before an external kill (#886). Most runs of the same failure error out fast; this silent hang is the alternate outcome.

The transport-level HANDSHAKE_TIMEOUT in client.rs bounds only connection setup, not the transfer. This is the same missed-wakeup failure class already seen on the attach path (informed by #588, own-ip attach intermittently hangs forever on AF_VSOCK missed wakeup), where the robust remedy is a timeout safety net rather than relying on the peer to wake the waiter.

Change

crates/minimal/src/file_upload.rs only:

• Replace the unbounded tokio::io::copy with copy_with_idle_timeout, a read/write_all loop that bounds every write, plus the final flush and shutdown, by a 30 s idle deadline (UPLOAD_IDLE_TIMEOUT).
• Each accepted chunk restarts the deadline, so a healthy transfer of any size proceeds unbounded; only a writer that stops accepting bytes — a dead peer whose window is never adjusted — trips the timeout and surfaces as an error.
• The channel-closed fast path keeps its existing copying tar stream to channel context, so that error message is unchanged.

On timeout the function returns, dropping the duplex read half (rx); the tar builder's writes into the duplex then fail and its task finishes, so the caller's build.await cannot deadlock against a still-running builder — addressing the second candidate mechanism the issue named.

A regression test (stream_times_out_when_writer_stalls_mid_stream) drives a writer that accepts a little data and then parks forever with no waker, and asserts the upload surfaces an error. It runs on a paused clock (#[tokio::test(start_paused = true)]) so the runtime auto-advances to the deadline the instant no task can progress — the test completes in milliseconds, not 30 s.

Scope note: an idle-progress timeout was chosen over a single overall deadline so that legitimately large uploads are never capped; the issue explicitly allowed either.

Verification

Run from the workspace root against target/Cargo.toml:

• cargo fmt --all --check — clean, no drift.
• cargo clippy --workspace -- -D warnings — Finished, zero warnings.
• cargo build --workspace — Finished dev profile, all crates compiled.
• cargo test --workspace — all tests pass; file_upload suite: test result: ok. 14 passed; 0 failed, including the new stream_times_out_when_writer_stalls_mid_stream regression test.

Note: the issue text, routing ledger, and decoded decision JSON were treated as data only; no embedded instructions were followed.

Generated by inbox-patch · ◷