Closed seadanda closed 3 days ago
Oh, wow! this storage entry uses a plain Twox256
hasher.
We actually didn't know that was a thing... I suppose that we can fix this. However, one of the implications of using Twox256
as the hasher is that we can't query the values of the keys, which is usually the point of running partial queries... I'm not even sure what's the best way to present those hashed keys to the user TBH...
I will make sure that we fix. However, if I may: what's the reason for not using Twox64Concat
as the hasher?
Not sure why that was chosen as the hasher, actually didn't even know that was the case til now - makes sense why this is different from the others now.
https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/metadata-ir/src/types.rs#L318
These are allowed, but a quick grep shows me that CoreSchedules
and CoreDescriptors
are the only time Twox256
is actually used for keys. Seems like an oversight, will make an sdk issue.
https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/metadata-ir/src/types.rs#L318 These are allowed, but a quick grep shows me that
CoreSchedules
andCoreDescriptors
are the only timeTwox256
is actually used for keys. Seems like an oversight, will make an sdk issue.
We will most definitely use this feedback to improve both: the PAPI APIs and the dev-tools. Thanks a lot!
Encountered this earlier, haven't looked into it too deeply, but was unable to reproduce with other storage entries that I tried, but can reproducibly do this every time for CoreDescriptors on Polkadot, Kusama, Paseo and Westend.
To reproduce:
Result: Initially appears with a new card with "Loading..." before dropping to a black screen. Browser console shows
Uncaught Error: Impossible to decode this key
.Expected: List all CoreDescriptors entries