Skip to content
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 storage item Staking.QueuedElected on block 29231 #5969

Open
jsdw opened this issue Sep 5, 2024 · 0 comments
Open

Cannot decode storage item Staking.QueuedElected on block 29231 #5969

jsdw opened this issue Sep 5, 2024 · 0 comments

Comments

@jsdw
Copy link

jsdw commented Sep 5, 2024

The error I run into is this:

Error: Unable to decode storage staking.queuedElected:: createType(ElectionResult):: decodeU8aStruct: failed at 0x4c1650c532ed1a8641e8922aa24ade0f… on compute (index 1/4): {"_enum":{"OnChain":0,"Signed":1,"Unsigned":2}}:: Unable to create Enum via index 76, in OnChain, Signed, Unsigned

To reproduce, run 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):

git clone https://github.com/jsdw/polkadot-historic-decoding-example.git
cd polkadot-historic-decoding-example/js
npm install
node index.js decode-storage-items --block 29231 --entry Staking.QueuedElected

The failure is because Staking.QueuedElected has the type ElectionResult in PJS, which looks like this:

  ElectionResult: {
    compute: 'ElectionCompute',
    slotStake: 'Balance',
    electedStashes: 'Vec<AccountId>',
    exposures: 'Vec<(AccountId, Exposure)>'
  },

I dug into old Substrate code and the correct type for this old block seems to be this:

    ElectionResult: {
      electedStashes: 'Vec<AccountId>',
      exposures: 'Vec<(AccountId, Exposure<AccountId, Balance>)>',
      compute: 'ElectionCompute'
  },

Changing the type to the above in PJS (and in the Rust decode stuff) gets everything decoding OK without any undecoded bytes etc. What I don't know is whether newer runtimes will expect a different type (eg the one currently present). However, offhand I tried some blocks, and the last block I could find where this storage entry had a value was 326344, and it still decoded correctly there (this block is halfway into runtime spec version 10).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

1 participant