-
Notifications
You must be signed in to change notification settings - Fork 363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fails to create Call
from OpaqueCall
argument for asMulti
#2753
Comments
So your issue is you are trying to create types using the API registry which will point to the current metadata. Extrinsics move around, modules move around, methods are added/removed between upgrade. So each type has a registry attached based on the types and metadata at that point. So use the registry used for the block to create any new types with metadata at that point in time. TL;DR Do this at the appropriate place - // any type registry, could be opaqueCall as well
// (but using block since it is passed from the parent)
const decoded = block.registry.createType('Call', opaqueCall);
console.log(JSON.stringify(decoded.toHuman(), null, 2)); |
Great, thank you! This works. To clarify, when you say the API registry points to the current metadata, is it the newest metadata for the chain? I was under the impression it would point to the metadata at block height the most recent query was made at, hence why I was trying to use the API registry to decode. |
Always newest, independent of queries made. Any types created during an |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
In the extrinsic
asMulti
, one of the parameters is a scale encodedcall
, which has a type alias of OpaqueCall. In Sidecar we decode the call to improve the readability. Recently though I found there are some successfulasMulti
call
arguments on Polkadot that polkadot-js cannot decode (failing with a createType error).Below is some code that shows both successful decoding and non-successful. The main commonality I found is that the ones that do not decode are
utility.batch
Calls, but I am not sure if this is just a coincidence:Which results in the following to the terminal:
For an example of the exact error that polkadot-js gives, for block 871651 the error is:
Not sure how to trouble shoot without trying to account for every byte in the encoded
Call
.The text was updated successfully, but these errors were encountered: