Add the Header::Hash type param to the metadata

[serban300]

We need this field to be in the metadata for the generated runtimes that we use for the bridges.

More details:
paritytech/parity-bridges-common#2669
paritytech/subxt#1247

[svyatonik]

👍 for us it is fine, but I wonder if it may break something else, so I'd wait for approval from those who are working on that code

[serban300]

@gupnik Could you please take a look on this PR to see if it's ok ? It's a very small change. From what I understand from the git history, I think that you added the #[scale_info(skip_type_params(Hash))] line and this PR removes it.

[bkchr]

I think having the skip there is more correct. You are abusing there with subxt the fact that the runtime and subxt is using Rust. Other languages can not just include these types by path. This type is also not really part of the of the type, it is the actual hashing that is being used.

[serban300]

I think having the skip there is more correct. You are abusing there with subxt the fact that the runtime and subxt is using Rust. Other languages can not just include these types by path. This type is also not really part of the of the type, it is the actual hashing that is being used.

I agree that having the skip there is more correct, but so far I couldn't find a good workaround that would enable us to keep generating the runtime apis if we keep the skip. So I don't know what would be the best solution. Still thinking of workarounds on our side.

Converted the PR to draft in the meanwhile.

[bkchr]

It gets even weirder if you look into the Config that you need to provide to subxt. It already includes the Hasher and the Header, both of the types we are speaking here about.

CC @jsdw

[serban300]

It gets even weirder if you look into the Config that you need to provide to subxt. It already includes the Hasher and the Header, both of the types we are speaking here about.

CC @jsdw

I am not very familiar with this, but I guess that config needs to be provided only if someone uses subxt for submitting the extrinsics. We only use subxt-codegen to generate the runtime api and we have our own code for building and submitting the extrinsics. Also I guess the hasher and the header in that config are the ones of the current chain. For our extrinsics it's the header and hash of the bridged chains, so it gets a bit more complicated.

But for someone that submits extrinsics using subxt, I think that config makes sense

[bkchr]

We only use subxt-codegen to generate the runtime api and we have our own code for building and submitting the extrinsics

I mean you are using the metadata of the target chain or? I mean I also have no real idea how subxt works, but @jsdw should be able to help here :P

[serban300]

I mean you are using the metadata of the target chain or?

Yes, we're only using the metadata of the target chain to get the definition of the Runtime Call. And with that we can build and submit the calls that we need from the relayers.

[serban300]

Closing this PR. I will think of alternatives.

[jsdw]

I left a response in the subxt issue for this (paritytech/subxt#1247).