You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is some ambiguity in how StorageMap keys are composed. It appears the are the concatenation of storage address (32 bytes), blake2 hash of key (16 bytes), and key itself (variable length). But there is an extra 1 byte needed.
@HCastano suggested this might be related to theQueryKind being set to OptionQuery.
We should check the storagemap source code and confirm - just in case this is not something which will reliably always be present, and our code breaks sometime.
See disussion in PR: #1170 (comment)
There is some ambiguity in how
StorageMap
keys are composed. It appears the are the concatenation of storage address (32 bytes), blake2 hash of key (16 bytes), and key itself (variable length). But there is an extra 1 byte needed.@HCastano suggested this might be related to the
QueryKind
being set toOptionQuery
.We should check the storagemap source code and confirm - just in case this is not something which will reliably always be present, and our code breaks sometime.
See also the client function we use to read the key value pairs:
subxt::storage::Storage::iter
The text was updated successfully, but these errors were encountered: