Observed on PR #259's coverage job (run 30834385118, ubuntu): the driven-sftp test session::tests::a_session_can_read_and_write_the_served_directory failed with the read-back returning empty bytes:
assertion `left == right` failed
left: []
right: [102, 114, 111, 109, ...] ("from the client")
The same test passed in the plain cargo test + clippy jobs on the same commit, and the PR's diff (thirtyfour bump + one driven-e2e fix) cannot affect driven-sftp - driven-e2e is even excluded from the coverage test invocation. So this is a timing flake that surfaces under llvm-cov instrumentation slowdown: a read-after-write race against the in-process test SSH server at session.rs:699.
Fix shape: make the test wait for the write to be durably visible (flush/close the handle before reading, or poll-with-deadline on the expected content) instead of assuming immediate read-after-write consistency.
🤖 Generated with Claude Code
https://claude.ai/code/session_015jEKvjBzVjaWLq6o5zg2PV
Observed on PR #259's coverage job (run 30834385118, ubuntu): the driven-sftp test
session::tests::a_session_can_read_and_write_the_served_directoryfailed with the read-back returning empty bytes:The same test passed in the plain
cargo test + clippyjobs on the same commit, and the PR's diff (thirtyfour bump + one driven-e2e fix) cannot affect driven-sftp - driven-e2e is even excluded from the coverage test invocation. So this is a timing flake that surfaces under llvm-cov instrumentation slowdown: a read-after-write race against the in-process test SSH server at session.rs:699.Fix shape: make the test wait for the write to be durably visible (flush/close the handle before reading, or poll-with-deadline on the expected content) instead of assuming immediate read-after-write consistency.
🤖 Generated with Claude Code
https://claude.ai/code/session_015jEKvjBzVjaWLq6o5zg2PV