The `close` listener wrote "disconnected" unconditionally, so a connection
that failed loudly -- the `error` listener having already written "cannot
reach <url> -- is improvise-ws-server running?" -- was immediately followed
by a close event replacing it with the vaguer of the two facts. The user saw
the least informative thing that happened.
This is the watchdog bug's family and deliberately NOT its fix. The watchdog
is for silence only, so it is disarmed; suppressing `close` outright would
hide a genuine mid-session disconnect, which is the one thing that listener
is really for. So the two cases are split rather than one being guarded.
A CORRECTION TO THE TICKET'S SUGGESTED MECHANISM: it proposed reading
`readyState` at close time, and that cannot work. `readyState` is already
CLOSED by the time a close listener runs, whichever happened, and the
CloseEvent cannot separate them either -- a refused connection and a
mid-session network drop are both code 1006 with `wasClean: false`. The only
discriminator is whether `open` ever fired, which the page must remember for
itself. Hence the `opened` flag.
Both arms go through `setShellFailure`, because a drop before the first frame
leaves the watchdog armed and "disconnected" is more precise than the guess
it would fire 8s later.
The header comment stating the `#status` vocabulary is updated in the same
commit: that fact is stated twice, and gotcha 48 says changing it is a grep.
VERIFICATION IS READING, and that is the whole budget. There is no browser
and no headless DOM here, so this is `node --check` (proved discriminating by
appending an unbalanced paren and watching it fail) plus confirmation that
every call app.js makes is in the generated .d.ts at the right arity:
on_frame/1, on_key_event/5, render_model/0, set_viewport/2, typed_cell/3.
Both wasm bundles still build. The listener itself has never been executed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Edward Langley
d3fe4aa041