Unparseable message: "ping"

[slyons]

I'm working with an API that seems to be doing things a bit backwards. Instead of the client sending the "ping" messages, it's the server, expecting the client to respond with the appropriate "pong", leading to the following error:

Error: RestartNeeded(Custom("Unparseable message: {\"method\":\"ping\",\"params\":null}"))

Barring rewriting the ping functionality to work in reverse, is there any way of handling unparseable messages?

[niklasad1]

Barring rewriting the ping functionality to work in reverse, is there any way of handling unparseable messages?

Unfortunately, no we just terminate the connection once that occurs.

The issue is not that the server is sends "pings" as JSON-RPC notifications but that the field jsonrpc is missing from the notification which is not according the spec

jsonrpc
A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0".

FWIW, it's really a weird implementation for a WebSocket server to send pings as JSON-RPC notifications which are not possible to answer/ACK. The reasonable thing is to use native WebSocket pings/pongs as jsonrpsee is doing.

I guess we could ignore those messages but a long time ago we decided to be explicit and terminate the connection when an error occurs.

/cc @lexnv @jsdw thoughts?

[slyons]

Could something be added as a message/transport error handler? Maybe something that returns ControlFlow to determine if the connection should continue?

…

On Mon, Mar 11, 2024, 13:43 Niklas Adolfsson ***@***.***> wrote: Barring rewriting the ping functionality to work in reverse, is there any way of handling unparseable messages? Unfortunately, no we just terminate the connection once that occurs. The issue is not that the server is sends "pings" as JSON-RPC notifications but that the field jsonrpc is missing from the notification which is not according the spec <https://www.jsonrpc.org/specification#response_object> jsonrpc A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0". FWIW, it's really a weird implementation for a WebSocket server to do send pings as JSON-RPC notifications which are not possible to answer/ACK. The reasonable thing is to use native WebSocket pings/pongs as jsonrpsee is doing. I guess we could ignore those messages but a long time ago we decided to be explicit and terminate the connection when an error occurs. /cc @lexnv <https://github.com/lexnv> @jsdw <https://github.com/jsdw> thoughts? — Reply to this email directly, view it on GitHub <#1319 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAKDO3J6KQI2WGC44FCOHTYXYJNRAVCNFSM6AAAAABEQ3FL56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBZGQYDQMJZGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jsdw]

If it wasn't too tricky to do, I'd have no objection to being able to set some handler that's called with any such messages and returns a boolean or whatever to determine whether to ignore it or stop (and then the default could be to stop).

In the future, if the client was to (optionally) return a "driver" thing that you need to poll to make progress, then I'd imagine that such errors would be emitted by the driver and then you'd have the chance to decide whether to ignore them or stop or whatever.