mirror of
https://github.com/PR0M3TH3AN/SeedPass.git
synced 2026-11-04 11:52:03 +00:00
Third and final layer of this one, and the actual mechanism. The daemon capped the line, wrote "request too large", and then destroyed the socket. Destroying a socket that still has inbound data pending makes the OS send an RST — and an RST discards the PEER's unread receive buffer, carrying off the refusal we had just written. On Linux the reply usually beat the reset; on macOS and Windows it did not, so the caller saw an unexplained hangup rather than a reason. `end()` sends FIN instead, which leaves the peer's buffer intact. Reads keep draining (the `refused` flag makes them cheap, and nothing accumulates), with an unref'd five-second timer as the backstop against a peer that never closes. Three commits for one test, and the layers were genuinely stacked: the test treated its own EPIPE as fatal, then wrote a megabyte without backpressure, and underneath both the daemon was resetting the connection instead of closing it. Only the last is a defect in shipped behaviour — a caller that sends too much has always been refused, but on two of three platforms it was never told why. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN