search

paritytech / json-rpc-interface-spec

29 stars 3 forks source link

`stop` event and `chainHead` responses #86

Closed josepot closed 1 year ago

josepot commented 1 year ago

While working on the tests for the @capi/substrate-client, I encountered an ambiguity that requires clarity.

Consider this scenario:

  1. The client issues a request for chainHead_unstable_header.
  2. Before the client receives a response, a stop event is triggered.

This raises some questions:

  1. Responsiveness: Will the server still dispatch a response to the chainHead_unstable_header request, even after a stop event?

  2. Response Type: If a response is sent, can we expect one of two outcomes?

    • The response is valid, implying the server fetched the required data before the followSubscription was invalidated.
    • If the followSubscription gets invalidated before data retrieval, the response will be a JSON-RPC error.

  3. Generalization: Does this behavior also apply to operation requests like chainHead_unstable_storage et al?

To sum up, I am operating under the assumption that a response will always be sent. For operation requests, any response type would result in the consumer receiving an ErrorDisjoined rejection. For non-operation requests like chainHead_unstable_header, I plan to forward the response as it is.

cc @tomaka

tomaka commented 1 year ago

If the followSubscription gets invalidated before data retrieval, the response will be a JSON-RPC error.

The response is actually null, not a JSON-RPC error. It's written in the spec.

There's also a note specifically for this:

Note: As explained in the documentation of chainHead_unstable_follow, the JSON-RPC server reserves the right to kill an existing subscription and unpin all its blocks at any moment in case it is overloaded or incapable of following the chain. If that happens, chainHead_unstable_header will return null.

josepot commented 1 year ago

If the followSubscription gets invalidated before data retrieval, the response will be a JSON-RPC error.

The response is actually null, not a JSON-RPC error. It's written in the spec.

Thanks for pointing that out! I actually missed that, my bad!

However, what about the other requests: chainHead_unstable_call, chainHead_unstable_unpin, chainHead_unstable_storage, etc:

Will the server still dispatch a response, even after a stop event? will it be a JSON-RPC error? 🙏

tomaka commented 1 year ago

However, what about the other requests: chainHead_unstable_call, chainHead_unstable_unpin, chainHead_unstable_storage, etc:

It's also written in the spec.

For call, body, storage:

If the followSubscription is invalid or stale, then "result": "limitReached" is returned (as explained above).

For unpin:

No error is generated if the followSubscription is invalid or stale. The call is simply ignored.

josepot commented 1 year ago

Thanks! Ok, now I get it. Sorry about that. So, basically, the only call that may not receive a response if "caught in the middle" is unpin, which kinda makes sense.

So, it could happen that the client sends an unpin request before the client has received the stop event, however the server was about to send it (or it had already sent it, but the client hadn't received it yet), in which case the server won't bother to respond back to the unpin request... I mean, for the sake of consistency, I would much rather getting back a response with an error or something, but it's not a big deal, I guess. Thanks!