Buffers Don't Respect Your Frame Boundaries

partial-frame buffering

Part of: Streaming Writing Assistant

Real networks don't deliver data in tidy, frame-sized packages. A single read() on the client might return half of an SSE frame, or three and a half frames, cut off wherever the network happened to hand you bytes. If your parser assumes every read boundary lines up with a frame boundary, it will occasionally slice a payload in half or drop a frame that arrived split across two reads. The buffering rule Whenever you receive raw bytes from a stream, append them to a running buffer , then split that buffer on the frame delimiter (\n\n). Every piece except the last one is a complete frame, safe to process. The last piece is whatever's left after the final delimiter you found. It might be empty, meaning the stream ended cleanly, or it might be a real frame that hasn't finished arriving. Either way, you hold it back and wait for more data before treating it as complete. This is the same frames.pop() move from lesson 4's JavaScript reader, now in Python, because it's a network-level problem rather than a language-level one. Whatever language you write the client in, the fix is identical: buffer, split, hold the tail. Why the tail can't just be processed anyway Suppose a chunk splits mid-f

Challenge: Recover the Stream, Drop the Incomplete Tail