search

paritytech / json-rpc-interface-spec

29 stars 3 forks source link

Question: how best to keep track of runtime updates #96

Closed jsdw closed 1 year ago

jsdw commented 1 year ago

I'd like to keep track of the latest finalized runtime (since I'm mostly interested only in finalized blocks).

If I subscribe to chainHead_follow, I'm told about the current runtime/finalized block in the Initialized event. But I'm not told about the runtime in subsequent Finalized events, only NewBlock ones. This means that, at present, I need to track any runtime info mentioned in new block events, and then when finalized events come through, associate the matching newblock runtime with it (if it exists).

So, a couple of questions:

  1. Does keeping track of finalized runtimes only in this way actually make sense, or is there a reason I should care about non-finalized runtime reports too?
  2. Would it make sense to report the runtime on Finalized events, to make this really easy to do?
josepot commented 1 year ago

In case it helps, this is how we are currently doing it.

jsdw commented 1 year ago

Thanks! Yup, that looks like pretty much exactly what I'll be doing as things stand :)

jsdw commented 1 year ago

I'll close this; It's not really too hard to track runtime updates in this way, and #97 ensures that there aren't any hairy edge cases to handle (may be worth a wee spec clarification to make this super clear). Anyway, we get a vec of finalized blocks back in the Finalized event, and so which runtime would be reported there (presumably the latest, but yeah, things start getitng more debatable).

tomaka commented 1 year ago

For what it's worth you can also take a look at this code: https://github.com/smol-dot/smoldot/blob/3ef35b9c364d4dd87d7786409d436113a785c9e8/full-node/src/json_rpc_service/legacy_api_subscriptions.rs

It's smoldot's implementation of the legacy API's subscription functions based on top of the chainHead_follow functions. It's maybe a bit wonky, but that's because the legacy API doesn't properly define how these functions should behave.

It's not exactly based on top of chainHead_follow but based on top of smoldot's "consensus service", but this consensus service has exactly the same logic of API as chainHead_follow.