fix: Use correct registry when parsing extrinsic call arguments
#323
Conversation
| @@ -396,11 +396,12 @@ export class BlocksService extends AbstractService { | |||
| * @param argsArray array of `Codec` values | |||
| */ | |||
There was a problem hiding this comment.
Should we put doc-comment for block too?
| @@ -414,7 +415,10 @@ export class BlocksService extends AbstractService { | |||
| * | |||
| * @param genericCall `GenericCall` | |||
| */ | |||
| @@ -363,11 +363,12 @@ export class BlocksService extends AbstractService { | |||
| * @param argsArray array of `Codec` values | |||
| */ | |||
| @@ -381,8 +382,11 @@ export class BlocksService extends AbstractService { | |||
| * | |||
| * @param genericCall `GenericCall` | |||
| */ | |||
|
LGTM apart from the doc-comments I think |
| const { sectionName, methodName, callIndex } = genericCall; | ||
| private parseGenericCall( | ||
| genericCall: GenericCall, | ||
| block: Block |
There was a problem hiding this comment.
Would it be possible to pass around the registry rather than the block? It would clarify the intent a bit (maybe it’s more efficient too?). Without knowing the context I think I would have had to read a fair amount of code before figuring out what the second params is for.
There was a problem hiding this comment.
I will change to just the registry. I actually did the whole block just for readability and to make it clear the registry is associated with the block
| } else { | ||
| newArgs[paramName] = argument; | ||
| } | ||
| } | ||
| } | ||
|
|
||
| return { | ||
| method: `${sectionName}.${methodName}`, | ||
| callIndex, |
There was a problem hiding this comment.
Why remove the callIndex here? It’s a private method so I guess it can change at any time, but curious why?
There was a problem hiding this comment.
Thats a mistake! Good catch!
closes #322
relates to polkadot-js/api#2753
Previously we were using the
ApiPromiseregistry to decodeOpaqueCalls. It turns out this registry only has the latest metadata and will not have historic metadata. So when trying to parse some historicCalls, the bit of code changed by this PR would fail because it had the incorrect metadata for decoding.This PR introduces the use of the blocks registry, which should always have the correct metadata to decode the extrinsics within. In theory we could use the registry off of any type from one of the historic queries, but I think using the block's registry is the is the most intuitive and readable.
Other note is that I updated all deps to latest versions.