-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot decode entry in storage item Proxy.Proxies
on block 1733218
#5974
Comments
Just for reference, the full list of entries decoded in Rust from the map are pasted below (only the one failure at index 43; everything else decodes ok). We can see that the values are well rounded numbers (and no leftover bytes encountered anywhere) which hint towards the decoding working OK there.
|
Ok, so the one entry that fails to decode decodes successfully and looks sane when using a format from the previous runtime, ie by stripping the 4 byte "delay" from the type: ProxyDefinition<AccountId, ProxyType, BlockNumber>:
delegate: AccountId
proxyType: ProxyType
# delay: BlockNumber Kian suggested that there may be the odd undecodeable state owing to storage migration errors, so perhaps this entry is one such case and it's still stored in the old format. |
I looked forward a bit and the specific Proxy.proxies entry with account ID 0x0E6DE68B13B82479FBE988AB9ECB16BAD446B67B993CDD9198CD41C7C6259C49 (address 165UCqvJQVAuCRj69NHwHJHcxwepjQWbEZPBTbD11n4QUM74) is still broken all the way until the current block (ie it won't decode properly with V14/V15 metadatas either, but all other entries in the map look OK). Given that, it might be that there's no sane fix for this without some exception being added. I think I'll just blacklist it in the decoding stuff so it's skipped. |
This can be reproduced in PolkadotJS UI using the following parameters:
storage entry: Proxy.Proxies
account ID / address: 1KvKReVmUiTc2LW2a4qyHsaJJ9eE9LRsywZkMk5hyBeyHgw
block hash: 0x539cf843cc3e6617a14c2bfb4602ffb946c93adaeafc3e0fb425ca86c151f559
The error I run into is this:
You can also reproduce the error by running these commands in a temp folder somewhere (these download a script I am using to decode historic storage and runs it with the entry and block mentioned in the title):
Other entries in this Proxy.Proxies map decode OK, for instance you can swap the address mentioned above with one of these (which point at previous entries in the map) and everything decodes fine with no leftover bytes:
14etN8LW2YB2WA7yBYDecyLFPpxMSaeV1nhxYbJi8uMJcfkD
15aKvwRqGVAwuBMaogtQXhuz9EQqUWsZJSAzomyb5xYwgBXA
Investigation
I've looked back at the historic Polkadot/Substrate code, and the type information in PJS looks perfectly valid to me. In addition, 42 other entries prior to this one from the same storage map decode OK, so this failure currently has me stumped!
From the metadata, the type we're trying to decode is
(Vec<ProxyDefinition<T::AccountId, T::ProxyType, T::BlockNumber>>, BalanceOf<T>)
.I checked out our old
polkadot
repo at tagv0.8.23
, which from releases page was when runtime spec version 23 was released. That points to master on substrate, so not knowing any better right now I looked at the tag date and checked out our oldsubstrate
repo withgit checkout $(git rev-list -n 1 --first-parent --before="2020-08-26 17:30" master)
to hopefully get the version used at release time.There,
ProxyDefinition
(in substrate/frame/proxy) looks like this:And the storage entry definition in the same file looks like this:
All of the types are from config, and we can see in the Polkadot runtime config (in polkadot/runtime/polkadot) that our
T::ProxyType
uses the following type:A simple enum with no special encoding.
BlockNumber
is defined as u32 andAccountId
as, essentially[u8; 32]
. These all line up with the PJS types.Decoding via the historic Rust decode logic gives some more detail than PJS provided:
This aligns with the PJS error, specifically the Unable to create Enum via index 189. We can see that the
delay
that was decoded in the previous entry has a suspicious value (3500394648
, when every otherdelay
Iin the prev entries in this map has a value of 0), indicating that some decode issue might have been encountered earlier than this, but I'm not sure where this error would be, since the types decoded previously are straightforward.All in all, I'm a bit stumped at present!
The text was updated successfully, but these errors were encountered: