EventSubscription decodes all events in block

[gregdhill]

Polling next() on the EventSubscription first decodes all events in the StorageChangeSet before filtering by the extrinsic index which means that if it encounters a type it does not know how to decode the method will Err(TypeSizeUnavailable).

The following example will panic:

        let (result1, result2) = futures::future::join(
            provider.clone().set_balance(10000000000 as Balance),
            provider.clone().set_custom_type(1 as CustomType)
        ).await;
        result1.unwrap();
        result2.unwrap();

[sander2]

The example above uses a single client. However, this also occurs when using different clients, using separate accounts in different processes. Crucially, the more active a blockchain is used, the more likely these decoding errors will occur. This makes scaling up really problematic. This is, in my opinion, a critical bug..

[ascjones]

I'm investigating this

[ascjones]

The fundamental problem is this: the raw data: Vec<u8> of a StorageChangeSet::changes item is an encoded list of EventRecords, which contains the Phase, the event itself and the list of topics.

Because of SCALE encoding we don't know up front the size of each encoded EventRecord so we need to decode or skip over each instance with the metadata we have available, even just to be able to filter by the extrinsic index which is stored in the Phase.

So unless the events related to your extrinsic are first in the list in the storage changeset, and if any of the preceding events contain any types whose size in unknown then we are unable to skip over them to arrive at the events you are interested in.

We are extremely aware of this limitation and in fact the focus of my work currently is the integration of scale-info type metadata into substrate which will solve this problem by having full metadata for all types.

However this is some months away from being ready for production, although we are working flat out to have it ready as soon as possible.

In the meantime, the simple but extremely imperfect workaround is simply to register all the unknown type sizes from your runtime on intialization of the events decoder..

I haven't done this in a while but it is worth looking at the mappings in https://github.com/polkadot-js/api. I can investigate whether there is an easy way to precompute any missing types from this.

[sander2]

Thanks for looking into this. Embedding metadata (specifically, the length of the event) seems indeed to be the best way forward. As an aside, using some kind of framing (e.g. COBS) would also work to be able to skip over events that fail to decode.

Anyway, I'm afraid your workaround is not sufficient - we do this already for explicit event listeners, but the problem is that subxt calls (the _and_watch functions) implicitly register a new event listener - one that we can not register additional type sizes to.

[ascjones]

but the problem is that subxt calls (the _and_watch functions) implicitly register a new event listener

Yes that is a problem, I will look at ways of improving the API to allow registering of global type sizes on Monday.

[ascjones]

@gregdhill @sander2 please have a look at #227, and let me know whether that is an acceptable solution for now.

[gregdhill]

Looks good @ascjones, when do you think this will be ready?

[ascjones]

It just needs to be reviewed and merged now, so should be this week hopefully.

[dvdplm]

Looks good @ascjones, when do you think this will be ready?

@gregdhill It would be good if someone from Interlay could take a look at the proposed code and try it out with your code to make sure it addresses the issues you have reported. Is that possible?

[sander2]

Hi @ascjones, @dvdplm, I just tested #227 and I can confirm that it indeed fixes the problem described in this issue. Many thanks for making the fix!