The Timeout That Corrupted the Next Message
IMPOSSIBLE_FRAME_LENGTH — one timeout poisons a persistent connection
Network Platform: Clients send valid length-prefixed messages, but after one soft timeout the Rust service reports impossible frame sizes. Reconnecting fixes the stream.
The trap: read_exact() may consume part of a header or payload before its future is cancelled. Retrying with a fresh buffer does not restore those socket bytes; the remaining payload is interpreted as the next header.
Your task
Fix `FrameReader::read_next_frame()` in `src/lib.rs`. Retain partial bytes in connection-owned state, use cancellation-safe incremental reads under one absolute deadline, and consume data only after the supplied parser finds a complete frame. CI interrupts headers and payloads at deterministic boundaries.
Book: The read timed out, so retry it. Prod: Cancelling a future does not undo I/O it already performed.
Skills you'll prove
Interview Tip
Cancelling an async operation does not roll back bytes already consumed. Tokio's read_exact is not cancellation-safe, so a timed-out framed read can leave the socket cursor mid-message. For resumable soft timeouts, I keep a persistent connection buffer, use cancellation-safe incremental reads under one deadline, and parse only complete frames. I validate lengths before allocation and distinguish clean EOF from truncation.