conflict between custom-types from different metadatas

[mission-liao]

Hi, I encounter an issue on Kusama when regsitering custom types from different metadatas, specifically, one is spec "9151" and another one is "9300". The type:[sp_runtime:DispatchError] in these two metadata are different

The one in 9151

sp_runtime:DispatchError {Type:enum TypeString: TypeMapping:[[Other empty] [CannotLookup empty] [BadOrigin empty] [Module [["index","U8"],["error","U8"]]] [ConsumerRemaining empty] [NoProviders empty] [Token sp_runtime:TokenError] [Arithmetic sp_runtime:ArithmeticError]] ValueList:[] BitLength:0 V14:true SpecVec:0}

The one in 9300

sp_runtime:DispatchError {Type:enum TypeString: TypeMapping:[[Other empty] [CannotLookup empty] [BadOrigin empty] [Module sp_runtime:ModuleError] [ConsumerRemaining empty] [NoProviders empty] [TooManyConsumers empty] [Token sp_runtime:TokenError] [Arithmetic sp_runtime:ArithmeticError] [Transactional sp_runtime:TransactionalError]] ValueList:[] BitLength:0 V14:true SpecVec:0}

sp_runtime:ModuleError {Type:struct TypeString: TypeMapping:[[index U8] [error [U8; 4]]] ValueList:[] BitLength:0 V14:true SpecVec:0}

The type of error field is different, it's U8 in 9151 and [U8; 4] in 9300, their length in bytes are different. The sp_runtime:DispatchError in 9330 won't get registered if I register metadata from 9151 first.

It seems better to separate those type registries (currenctly in global) for different spec-versions (even different chain, for example, using this library for DOT and KSM simultaneously). Do I miss anything?

[freehere107]

@mission-liao Hi, For the case that the historical runtime has changed, you can handle it by setting the spec

scale.go/types/base.go

Line 15 in 761a35d

Spec int

Here is an example

https://github.com/itering/scale.go/blob/master/event_test.go#L35

The type of metadata v14 registered multiple times will be distinguished by spec version

[mission-liao]

Lovely, I didn't expect the solution is so simple and intuitive.

I use itering/substrate-api-rpc simultaneously, and generate types.Metadata via substrate-api-rpc/metadata.RegNewMetadataType. Now there is no way to perform this setting.

I propose to make a PR to accept ScaleDecoderOption in MetadataDecoder.Init, then the spec parameter in RegNewMetadata could be assigned to MetadataDecoder.

But make the behavior default might be unexpected to others. I can add a flag or options hidden by vargs, and the default behavior is the original one.

What do you think?

[freehere107]

@mission-liao This is a good idea, I will add it in the next update