Drink backend: support runtime call

[pmikolajczyk41]

Since inkdevhub/drink#36 is done, we can finally support arbitrary runtime calls in e2e tests. However, the solution is kinda tricky.

Problem

In drink! we have strongly typed runtime calls. This is because we keep the runtime directly, in-memory, and thus we have access to the RuntimeCall enum family. And thus there's no need of dynamic dispatch.

In standard e2e backend (i.e. node+subxt) we must have only dynamic dispatch. This is because we support running a node with an arbitrary runtime, and therefore we cannot statically generate runtime types, including RuntimeCall enum family.

But in order to support using both backends with the same test code, we have to provide a common interface...

Solution

We can't make ChainBackend::runtime_call statically typed, since for subxt_client::Client there is no way of providing correct types. Hence, we have to leave the API as it is (i.e. dynamic dispatch with pallet and call as strings and call data as subxt::Value wrappers).

For the drink! implementation we do following mumbo-jumbo:

• we get metadata from the runtime
• using subxt we create a valid call object using arguments and metadata
• we encode the call object
• we decode it to the RuntimeCall object
  🤷‍♂️

Note

Since drink::MinimalRuntime and substrate-contracts-node's runtime use different addressing, the testcases that relate to runtime calling are compatible with only one backend. However, notice that this is the incompatibility of used runtimes, not backends, and thus it's okay.

[SkymanOne]

You could potentially do some hacky type inference here, but current solutions looks good enough to me.

[SkymanOne]

Can we make this one optional too and dependant on the drink feature?

[pmikolajczyk41]

oh, sure, my bad; done

[ascjones]

In standard e2e backend (i.e. node+subxt) we must have only dynamic dispatch. This is because we support running a node with an arbitrary runtime, and therefore we cannot statically generate runtime types, including RuntimeCall enum family.

Yes and no, I think it would be beneficial to define a minimal set of hardcodeed common calls that are useful and supported by both substrate-contracts-node and drink. Balances::transfer etc... (in fact we already do this for the pallet_contracts calls instantiate, call etc.

Of course people can still target their own custom node and then if they don't satisfy that API then calls simply return an error "Not implemented for target node".

Either way this dynamic API is required and very useful.

[pmikolajczyk41]

Either way this dynamic API is required and very useful.

Sure it is, I'm not attacking it. Just saying that it is not (and won't be) natively supported in drink