From Wave 5 WebSocket audit, finding F-P-13. Severity: medium.
Code
kalshi/ws/dispatch.py:79-83 routes to on_error only when msg_type == "error". Top-level error envelopes are handled correctly.
The gap
The AsyncAPI spec also allows server-side errors tied to a specific subscription's sid (e.g., an error mid-stream for a sub that's still active). If the server sends a message with type other than "error" but carries error semantics (e.g., schema-violating payload, malformed message), it falls through to the unknown-type log path at dispatch.py:86-95 and is silently dropped.
Suggested fix
Either:
- Document that only top-level
type="error" envelopes are routed to on_error; channel-level errors must be inspected by the consumer.
- Or extend the dispatcher to also check for an
error payload field on otherwise-typed messages and route those to on_error.
Pin whichever behavior is intentional with a regression test.
From Wave 5 WebSocket audit, finding F-P-13. Severity: medium.
Code
kalshi/ws/dispatch.py:79-83routes toon_erroronly whenmsg_type == "error". Top-level error envelopes are handled correctly.The gap
The AsyncAPI spec also allows server-side errors tied to a specific subscription's sid (e.g., an error mid-stream for a sub that's still active). If the server sends a message with
typeother than"error"but carries error semantics (e.g., schema-violating payload, malformed message), it falls through to the unknown-type log path atdispatch.py:86-95and is silently dropped.Suggested fix
Either:
type="error"envelopes are routed toon_error; channel-level errors must be inspected by the consumer.errorpayload field on otherwise-typed messages and route those toon_error.Pin whichever behavior is intentional with a regression test.