Expose types for the overarching Call, Error, Event types

[rphmeier]

Currently, using these with e.g. https://github.com/paritytech/scale-value requires doing manual decoding of the first byte, hunting down the pallet index in RuntimeMetadataV14::pallets, and then decoding the remainder of the payload with the types exposed in PalletMetadata. The RuntimeMetadataV14 should expose all of these overarching types.

[ascjones]

I can think of two ways to approach this:

1. Add those type definitions as fields at the top level in the metadata itself: requires initializing them here. Pros it is guaranteed to describe the exact shape of those generated types. Cons are that it would introduce some redundant information (although arguably a small amount).

2. Expose some methods in frame-metadata to dynamically construct those type definitions based on the information already available. Pros are that it will not require a change to substrate so you can start using it immediately. Cons are that there is no absolute guarantee the types would be exactly the same as the macro generated types in substrate, and also depends on the ability to dynamically construct "portable" type definitions (ongoing but incomplete work: Construct PortableRegistry dynamically at runtime scale-info#164)

Possibly you could start with 2. and add the methods, and while waiting for 1 to propogate throrugh to node implementations. Then the methods could just be changed to access the fields once available.

[jsdw]

We deal with this in Subxt at the moment by generating the relevant root Call, Event and Error types and then having them implement a trait that ends up looking like:

impl ::subxt::events::RootEvent for Event {
    fn root_event(
        pallet_bytes: &[u8],
        pallet_name: &str,
        pallet_ty: u32,
        metadata: &::subxt::Metadata,
    ) -> Result<Self, ::subxt::Error> {
        use subxt::metadata::DecodeWithMetadata;
        if pallet_name == "System" {
            return Ok(Event::System(system::Event::decode_with_metadata(
                &mut &*pallet_bytes,
                pallet_ty,
                metadata,
            )?));
        }
        if pallet_name == "Scheduler" {
            return Ok(Event::Scheduler(scheduler::Event::decode_with_metadata(
                &mut &*pallet_bytes,
                pallet_ty,
                metadata,
            )?));
        }
        if pallet_name == "Preimage" {
            return Ok(Event::Preimage(preimage::Event::decode_with_metadata(
                &mut &*pallet_bytes,
                pallet_ty,
                metadata,
            )?));
        }
        // ...
    }
}

This exists to work around the fact that the type Id for the generated type isn't in the type info, and lets us instead use the pallet name to, in the above case, encode arbitrary events.

All that to say, I think exposing the error_ty and event_ty at the top level of the metadata would be very useful for us and save a bunch of codegen and boilerplate, so I'm all for it! We'll endeavour to add this to V15 metadata. (we'll expose the call_ty already in #43 as part of the extrinsic details)

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/stablising-v15-metadata/2819/1

[lexnv]

The paritytech/substrate#14143 PR closes this