002d1f76

fix(web): headFrame overflowed on a wire-declared length; bound the replay retries

a73x   2026-08-13 12:52

fix(web): headFrame overflowed on a wire-declared length; bound the replay retries

Review round 2. The first item is mine, introduced by the commit that
added headFrame two commits ago.

`off + payload_len > capacity` takes payload_len straight off the wire.
A 14-byte message declaring 0xFFFF_FFFF_FFFF_FFFF overflows the addition:
a panic in Debug — which is the DEFAULT build — and in ReleaseFast a wrap
to a permanent .incomplete, so the tile waits forever for a frame that
was never coming. One message per tile was enough, from anything that got
past the Origin gate. Written as a subtraction on the right now, with
`capacity < off` guarded because headFrame is pub and nothing promises a
caller's buffer outgrows a 14-byte header. Pinned at u64 max, at
maxInt-13, at the capacity edge either side, and at capacities below the
header itself; confirmed by restoring the old arithmetic and watching the
new pins panic.

The capacity check also earned a proper comment. It is not tidiness: it
is what keeps fillMore off a full buffer. fillMore calls
rebase(bufferedLen + 1) and std's defaultRebase asserts on exit that
`buffer.len - seek >= capacity`, which cannot hold once the buffer is
full — so saying .too_big BEFORE a frame can fill the buffer is the thing
standing between a hostile length and an assert.

The rest of the round:

  - Both new recovery paths in mux.js were unbounded retry loops. A frame
    over the staging cap and a core that refuses to apply both answered
    with a re-attach, and the daemon answers a re-attach with the same
    snapshot that just failed. Bounded now on the machinery the socket's
    own reconnect already had — same schedule, same ceiling — after which
    the tile lands on a terminal badge ('frame too big' or 'replay
    failed') and sends nothing further. sendAttach is gated on that flag
    so the `up` control message cannot talk it back into asking. A
    genuinely new socket clears it: the hub may have been restarted onto
    a session where the offending frame does not exist. Verified in a
    real browser by breaking stage() — 3 attaches, then silence for 13s,
    then recovery to 'up' on a fresh socket.
  - The dead-leg ping now runs INSIDE dialLoop too, against one clock
    carried by pointer. A reconnect is exactly when a browser is most
    likely to have died and exactly when nothing else is watching;
    resetting the clock on the way out would have made the check blind
    for the length of the outage instead of merely late.
  - test/wsclient.zig answers pings with a pong, and its comment saying
    the hub never sends one is no longer false. It also sends ONE
    unsolicited pong right after the upgrade — RFC 6455 allows that as a
    one-way heartbeat — so every hub e2e scenario exercises the pong path
    now instead of nothing exercising it until a 30s timer no test waits
    for. That path matters because readSmallMessage swallows pongs and
    loops to the frame behind them, which is the blocking hazard the
    whole gate exists to avoid.
  - verify.js pins the instantiate() SHAPE: Module in, bare Instance out;
    bytes in, {module, instance} out. That difference is what shipped a
    page unable to start at all, with every export assertion passing.
  - The finally-comment on sendPaste was overclaiming. It closes the
    bracket when a chunk fails to STAGE; it does nothing when the socket
    dies mid-paste, where the end marker never transits and the
    application is left in paste mode with state no reconnect can clear.
    Said plainly, and untreated in v1.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>