Fix type enumeration for stripped metadata in subxt.#23
Conversation
|
When you On the other hand, if you call |
|
There might be a bug in scale-info, I just noticed that in |
typegen/src/utils.rs
Outdated
|
|
||
| // First, group types if they are similar (same path, same shape). | ||
| for (ty_idx, ty) in types.types.iter().enumerate() { | ||
| // Note: ty_idx and ty.id might be different |
There was a problem hiding this comment.
Hmm, I don't think that should be the case, but maybe we have never really checked that ID variable.
I can see in scale_info::PortableRegistry::retain that we don't seem to update that type ID to reflect where its new location in the vec will be (https://github.com/paritytech/scale-info/blob/1e02764a1b6a59ef9e977750f2a60947d7dd47d1/src/portable.rs#L115) so probably we should fix that (unless @lexnv you can remember why we wouldn't have updated that Id too?).
There was a problem hiding this comment.
Let's point this comment to your scale-info PR to fix it and make clear it's a bug :)
typegen/src/utils.rs
Outdated
| if types_equal_extended_to_params(&ty.ty, ty_b) { | ||
| group.push(ty.id); | ||
| let other_ty_in_group_idx = group[0]; // all types in group are same shape; just check any one of them. | ||
| let other_ty_in_group = types.types.get(other_ty_in_group_idx).expect("ty exists"); |
There was a problem hiding this comment.
might as well use types.resolve() here I guess? all it does is a get under the hood and then gives back .ty :)
3 participants
I discovered that when retaining only parts of the metadata in subxt, we can end up with types where their
idand theirindexin theVecthey are held in do not line up.This caused the ui-tests to fail on the subxt core PR, see this action run.
I verified locally that with this change the UI-tests succeed again in subxt.
Though I suspect that there is a deeper problem somewhere and that we actually do not want to have the index and id of types to differ anywhere.
Let's just push this fix.