Files
SeedPass/js
thePR0M3TH3ANandClaude Opus 5 bea89f1953 Close the oversized connection with FIN, not RST, so the reason survives
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
2026-08-20 14:59:53 -04:00
..