mirror of
https://github.com/morluto/rea.git
synced 2026-10-23 06:12:29 -05:00
Dery Ferdikaandmorluto
26573c3aa4
* fix(hopper): bound bridge request frames like the Cutter bridge The Hopper bridge read each request with an unbounded readline, so a peer that never wrote a newline kept Hopper allocating for as long as it kept writing. The Cutter bridge already refuses a frame above MAX_FRAME_BYTES; the Hopper bridge had no request ceiling at all. Read the request line with a 16 MiB bound and refuse a line that fills the limit without a terminator, using the existing invalid_request diagnostic before closing the connection. Such a line cannot be answered or resynchronized, because its remainder would be read as the next request. The response direction is unchanged, so large decompilation results still flow, and every dispatchable method carries small bounded parameters. The stalled-line case keeps its connection open instead of half-closing it, so the test pins the exact ceiling: a bound one byte larger waits for a byte the peer never sends and fails instead of passing quietly. Validation: npm run check:fast (typecheck, lint) passed uncached, and the new boundary test passed against the real bridge over socket pairs at the frame limit and above it. Removing only the read bound makes the same test fail, and widening the bound to one byte past the limit fails it too. The Hopper boundary and bridge-packaging suites report the same 17 failing files and 126 failing tests before and after this change on this Windows host; those failures are POSIX-only probes (Unix socket directories, os.statvfs) unrelated to this diff. Native macOS Hopper and real-client traffic were not run. * fix(bridges): exclude line delimiter from payload limit * test(hopper): cover partial request at EOF --------- Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>