6

While fetching blocks from kusama, I get the following message in the block range [1, 461692]: Unable to map u16 to a lookup index

I suppose this has to do with the types being used in the old blocks. Is there a types bundle that I can use with the polkadot-js api for the earlier blocks in Kusama network

1
  • can you show a chunk of code or link to it?
    – Squirrel
    Mar 23, 2022 at 10:07

1 Answer 1

7

This was an issue on older versions of the JS API. This was fixed in version 7.10.1 - https://github.com/polkadot-js/api/releases/tag/v7.10.1

The background to this is that to support multiple versions of metadata (Kusama starts on v9, it is now on v14), the metadata gets upgraded, i.e. when a block is retrieved for metadata v9, it is converted internally to v14. This means that internally to the API one version is used - the alternative would be to support codepaths for metadata v9, v10, v11, v12, v13 and (now) v14.

(As an aside: It could have been worse... and was worse at some point. We dropped support for v0-v8 a while back, the first block on Kusama uses metadata v9, so the cut-off point was set there)

As part of this metadata upgrade process to the latest version (in this case v14), some types are added to the type registry used in the v14 metadata specification, so basically we emulate what the node returns. In this case u16 was not added as part of this metadata-to-latest upgrade process, so the built-in <pallet>.palletVersion(): u16 storage entry couldn't work as expected and the internal decoration of this storage entry yielded the above log.

For Kusama/Polkadot the API doesn't need additional types, it ships with all historic info for the various upgrades. To fix your case, upgrade to at least @polkadot/api 7.10.1 (most recent is certainly best).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.