Add possibility of executing or mocking additional inherents in xcm-emulator

[girazoki]

With the addition of #8083 there is no possibility right now of making the xcm-executor work with custom inherents. Custom inherents are usually driven by killing a storage item of the form wasInherentSet on_initialize and asserting that such inherent was set on_finalize. Before the xcm-emulator worked as these hooks were running just for the ParachainSystem pallet, but now, they run for all pallets.

My proposal is to add an item to the xcm-emulator parachain configuration of the form AdditionalInherentCode, which simply executes code that returns a DispatchResult. Whether users want to mock a storage item or run the inherent is up to them, this hook would allow them to do both.

This item is optional, meaning that if it is non-set then it would do nothing

[girazoki]

@bkontur what do you think about this?

[bkontur]

@bkontur what do you think about this?

Actually, I was thinking about the same (or a similar) solution - to place the actual inherents behind a trait or callback (with a default implementation for set_validation_data) - when I was adding/refactoring set_validation_data.dispatch and timestamp_set.dispatch to support AllPalletsWithoutSystem::on_finalize.

However, I didn’t want to introduce a major breaking change at that time, and I also wasn’t sure whether the callback would require any parameters. For example, we actually need para_id, relay_block_number, and parent_head_data for set_validation_data.

@girazoki How do you plan to use fn execute_additional_inherents()? Do you have an example? You don’t need any inputs?

[girazoki]

set_validation_data

In our case, we are simply thinking about "mocking" the appropriate storage items on the pallets to make them think inherents have passed correctly, so we would not need any parameters. but it is true that if one would be willing to add the inherent call, then we might require some of the parameters.

We can add some parameters, like those we add for set_validation_data, and re-iterate if someone needs some more additional info. how does that sound?

[girazoki]

set_validation_data

In our case, we are simply thinking about "mocking" the appropriate storage items on the pallets to make them think inherents have passed correctly, so we would not need any parameters. but it is true that if one would be willing to add the inherent call, then we might require some of the parameters.

We can add some parameters, like those we add for set_validation_data, and re-iterate if someone needs some more additional info. how does that sound?

However one thing I just realized is that all that information should already be available in the cumulus parachainSystem pallet for anyone to use it after the set_validation_data inherent runs. so people can read them from there too, eliminating the need of parameters like timestamp, block number or headData

[bkontur]

In our case, we are simply thinking about "mocking" the appropriate storage items on the pallets to make them think inherents have passed correctly, so we would not need any parameters.

It seems like a bit of a hack or workaround, and I don't see any parallel with the existing pallet flow (on_initialize / on_finalize), but for testing purposes, it's probably fine. I think we could potentially handle inherents here the same way a real node/client does — by using the ProvideInherent trait and supplying inherent providers, instead of hard-coded calls like set_validation_data.dispatch, timestamp_set.dispatch, or AdditionalInherentCode::on_new_block. But that might be unnecessary complexity without much added value.

If you only need to trigger this once when the chain starts, you can use this on_init:
https://github.com/paritytech/polkadot-sdk/blob/master/cumulus/parachains/integration-tests/emulated/chains/parachains/testing/penpal/src/lib.rs#L41-L47

But if you really need it on every block, then I'd say let's stick with AdditionalInherentCode::on_new_block without params and see.

[bkontur]

/cmd prdoc --audience runtime_dev