search

paritytech / json-rpc-interface-spec

30 stars 3 forks source link

docs: improve `operationInaccessible` event #121

Closed josepot closed 10 months ago

josepot commented 10 months ago

cc @tomaka

tomaka commented 10 months ago

No, the sentence is correct, I don't see why you think that this event is specific to storage

josepot commented 10 months ago

I don't see why you think that this event is specific to storage

Because the very next sentence in the docs states that:

The operationInaccessible event is produced if the JSON-RPC server was incapable of obtaining the storage items necessary for the given operation.

So, either this event is just unique to storage operations (in which case the change that I'm proposing make sense), or it isn't.

If it is in fact not unique to storage opoerations, then we should either remove the confusing sentence about why the event is produced or explain why operations other than storage can also trigger this event.

josepot commented 10 months ago

I'm guessing that the other operation that can also trigger this event must be chainHead_unstable_body, since it's probably just sugar for accessing the storage entry of System.ExtrinsicData? If that's the case, I'm starting to think that we should probably remove chainHead_unstable_body from the API.

Ahhh, wait, of course: chainHead_unstable_call also requires from a storage access to :code, so I guess that if the storage read is failing, then it will also trigger this event... I see 🤔

But wait, if the consumer passed the withRuntime parameter set to true, then chainHead_unstable_call calls shouldn't trigger this event, correct?

tomaka commented 10 months ago

You're overthinking it, and it's just the next sentence that must mention that it can happen if failing to retrieve the body.

I'm guessing that the other operation that can also trigger this event must be chainHead_unstable_body, since it's probably just sugar for accessing the storage entry of System.ExtrinsicData? If that's the case, I'm starting to think that we should probably remove chainHead_unstable_body from the API.

It's not just sugar. If anything, it's System.ExtrinsicData that should be removed.

Ahhh, wait, of course: chainHead_unstable_call also requires from a storage access to :code, so I guess that if the storage read is failing, then it will also trigger this event... I see 🤔

call reads the storage from the network because doing a runtime call accesses the storage.