fix(perry-ext-ws): #813 — deliver server-level wss.on('message'/'close') events#814
Merged
Conversation
…e') events
The v0.5.572 perry-stdlib→perry-ext-ws port dropped the server-level
listener path. perry-ext-ws only delivered `message`/`close` events to
*per-client* listeners (`WS_CLIENT_LISTENERS`), so a server-level
`wss.on('message', (ws, data) => …)` / `wss.on('close', (ws) => …)`
handler — valid in perry-stdlib::ws and used by perry-hub — never fired.
Two defects, both fixed here mirroring perry-stdlib::ws semantics:
1. `drive_server_client_io` race-guard: `has_listener` only consulted
the per-client map, so an inbound frame for a server-only handler
was parked on `c.messages` forever and no `PendingWsEvent::Message`
was ever pushed. Now also checks the parent `WsServerHandle` via
`WS_CLIENT_PARENT_SERVER` → `listeners_on_server(sh, "message")`.
2. `js_ws_process_pending` `Message`/`Close` arms had no parent-server
fall-through. When per-client listeners are empty, fall through to
the parent server's listeners — `message` → `call2(ws_id, data)`,
`close` → `call1(ws_id)` — matching `crates/perry-stdlib/src/ws.rs`.
This was the residual root cause behind #746 (closed assuming a
Linux-only pure-WS symptom; it is neither Linux-specific nor a pump
issue) that persisted after the #747 fastify-pump fix (v0.5.904).
Validated end-to-end: perry-hub recompiled on Linux with this patch
on v0.5.912 — `wss.on('connection')`, server-level `wss.on('message')`
(worker_hello → "Worker connected"), and real workers all fire
correctly. `cargo check -p perry-ext-ws --release` clean.
Closes #813. Refs #746, #747.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #813 — the residual root cause behind #746 that persisted after the #747 fastify-pump fix (v0.5.904) shipped in v0.5.912.
perry-ext-wsonly deliveredmessage/closeevents to per-client listeners (WS_CLIENT_LISTENERS). A server-levelwss.on('message', (ws, data) => …)/wss.on('close', (ws) => …)handler — valid inperry-stdlib::wsand used byperry-hub— never fired. (connectionalready worked because it dispatches vialisteners_on_server.) The v0.5.572 perry-stdlib→perry-ext port dropped this server-level path.Two defects, both fixed (mirroring
crates/perry-stdlib/src/ws.rs)drive_server_client_iorace-guard — the Implement node:http / node:https / node:http2 + WebSocket upgrade for npm-ecosystem HTTP server compat #577 Phase 4has_listenerguard only checked the per-client map, so an inbound frame for a server-only handler was parked onc.messagesforever and noPendingWsEvent::Messagewas ever pushed. Now also checks the parentWsServerHandle(WS_CLIENT_PARENT_SERVER→listeners_on_server(sh, "message")).js_ws_process_pendingMessage/Closearms — no parent-server fall-through. When per-client listeners are empty, fall through to the parent server's listeners:message→call2(ws_id, data),close→call1(ws_id), matching perry-stdlib::ws.Validation
cargo check -p perry-ext-ws --release— clean.perry-hubrecompiled on Linux x86_64 with v0.5.912 + this patch. Before:wss.on('connection')fired butwss.on('message')never did (noWorker connected). After:connection, server-levelmessage(worker_hello →Worker connected), and real workers (oakhost-tart, azure-sign-win) all connect and round-trip correctly. Hub has been serving production traffic on this build.Notes / follow-ups
'error'server fall-through is intentionally not included here (perry-stdlib uses server"client_error"for per-client errors vs"error"forServerError; the hub doesn't depend on it). Worth a parity pass separately.wss.on('message')echo + single-frame client) would lock this down — happy to add if you'd like it in this PR.Closes #813. Refs #746, #747.