Sidecar 19.2.2 fails to decode Basilisk block

Description

Fetching block using sidecar v19.2.2 returns error

{
"code": 500,
"message": "createType(SignedBlock):: Struct: failed on block: {\"header\":\"Header\",\"extrinsics\":\"Vec<Extrinsic>\"}:: Struct: failed on extrinsics: Vec<Extrinsic>:: createType(ExtrinsicV4):: createType(ExtrinsicSignatureV4):: decodeU8aStruct: failed at 0x7c2371230cc4289cbdc36ac0880f435d… on signer (index 1/5): {\"_enum\":{\"Id\":\"AccountId\",\"Index\":\"Compact<AccountIndex>\",\"Raw\":\"Bytes\",\"Address32\":\"H256\",\"Address20\":\"H160\"}}:: Unable to create Enum via index 124, in Id, Index, Raw, Address32, Address20",
"stack": "Error: createType(SignedBlock):: Struct: failed on block: {\"header\":\"Header\",\"extrinsics\":\"Vec<Extrinsic>\"}:: Struct: failed on extrinsics: Vec<Extrinsic>:: createType(ExtrinsicV4):: createType(ExtrinsicSignatureV4):: decodeU8aStruct: failed at 0x7c2371230cc4289cbdc36ac0880f435d… on signer (index 1/5): {\"_enum\":{\"Id\":\"AccountId\",\"Index\":\"Compact<AccountIndex>\",\"Raw\":\"Bytes\",\"Address32\":\"H256\",\"Address20\":\"H160\"}}:: Unable to create Enum via index 124, in Id, Index, Raw, Address32, Address20\n    at createTypeUnsafe (/Users/user/Desktop/repos/substrate-dev-tools/node_modules/@substrate/api-sidecar/node_modules/@polkadot/types-create/cjs/create/type.js:54:22)\n    at TypeRegistry.createTypeUnsafe (/Users/user/Desktop/repos/substrate-dev-tools/node_modules/@substrate/api-sidecar/node_modules/@polkadot/types/cjs/create/registry.js:230:52)\n    at RpcCore._formatOutput (/Users/user/Desktop/repos/substrate-dev-tools/node_modules/@substrate/api-sidecar/node_modules/@polkadot/rpc-core/cjs/bundle.js:331:25)\n    at RpcCore._formatResult (/Users/user/Desktop/repos/substrate-dev-tools/node_modules/@substrate/api-sidecar/node_modules/@polkadot/rpc-core/cjs/bundle.js:169:20)\n    at callWithRegistry (/Users/user/Desktop/repos/substrate-dev-tools/node_modules/@substrate/api-sidecar/node_modules/@polkadot/rpc-core/cjs/bundle.js:190:25)\n    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)",
"level": "error"
}

if I try using older version 19.1.0 it works. Same for fee-estimate endpoint

error=Unable to fetch fee info, cause=createType(Extrinsic):: createType(ExtrinsicV4):: createType(ExtrinsicSignatureV4):: decodeU8aStruct: failed at 0x443c0ba8f048601bd709b475301f5200… on signer (index 1/5): {"_enum":{"Id":"AccountId","Index":"Compact<AccountIndex>","Raw":"Bytes","Address32":"H256","Address20":"H160"}}:: Unable to create Enum via index 68, in Id, Index, Raw, Address32, Address20, stack=Error: createType(Extrinsic):: createType(ExtrinsicV4):: createType(ExtrinsicSignatureV4):: decodeU8aStruct: failed at 0x443c0ba8f048601bd709b475301f5200… on signer (index 1/5): {"_enum":{"Id":"AccountId","Index":"Compact<AccountIndex>","Raw":"Bytes","Address32":"H256","Address20":"H160"}}:: Unable to create Enum via index 68, in Id, Index, Raw, Address32, Address20
    at createTypeUnsafe (/opt/substrate-api-sidecar/node_modules/@polkadot/types-create/cjs/create/type.js:54:22)
    at TypeRegistry.createType (/opt/substrate-api-sidecar/node_modules/@polkadot/types/cjs/create/registry.js:224:52)
    at TransactionFeeEstimateService.fetchTransactionFeeEstimate (/opt/substrate-api-sidecar/build/src/services/transaction/TransactionFeeEstimateService.js:34:42)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async TransactionFeeEstimateController.txFeeEstimate (/opt/substrate-api-sidecar/build/src/controllers/transaction/TransactionFeeEstimateController.js:66:65)
    at async /opt/substrate-api-sidecar/build/src/controllers/AbstractController.js:222:9

Steps to Reproduce

Run sidecar locally using wss://basilisk-rpc.dwellir.com and try to fetch block=6808229 using http://localhost:8080/blocks/6808229. It should return an error.

Expected vs. Actual Behavior

Should work in the same way as it was on the older 19.1.0 version.

Hello @nfekunprdtiunnkge , I could reproduce the error. I am looking into it.

Hello @nfekunprdtiunnkge , after extensive debugging with the help of @TarikGul and @bee344, @TarikGul identified the issue, which is related to the types bundle. So to make Sidecar work with Basilisk, you now need to include the Basilisk types bundle. Instructions on how to do this can be found here, but you can also follow the steps below:

Use the generate-type-bundle tool
Create a directory where you would like to save the "typesBundle.json" file
Run the command generate-type-bundle -p "PATH-TO-YOUR-DIRECTORY" -s basilisk
You should see a message that says "Succesfully generated your types bundle. Exiting."
The "typesBundle.json" file should be in the directory you specified
Now you can update the .env file you use to start Sidecar to point to the newly created typesBundle file. An example is shown below:
```
SAS_SUBSTRATE_URL=wss://basilisk-rpc.dwellir.com
SAS_SUBSTRATE_TYPES_BUNDLE="FULL-PATH-TO-DIRECTORY/typesBundle.json"
```
Then start Sidecar with that .env file and query http://localhost:8080/blocks/6808229 which now decodes the block as expected :

{
  "number": "6808229",
  "hash": "0x7cca886df0bee3028ec465ece5c6ae5e6b09e2510dba7a67fc55d013d1d55352",
  "parentHash": "0x4f63a68b1f8c8191c7f0276d27111a19dba6a85f647c31b8f26119ce1a565b2e",
  "stateRoot": "0x54244a1f6450a5979828f87fc1174b880948fdccc69b18c896c8a742bdf22eeb",
  "extrinsicsRoot": "0x8d6d896c58b0f83fa1c4c7b20159bd07ab2ead090de8f50802c9985c737a0b8d",
  "authorId": "bXijiBC3hdApKJkVqneQW7u2qX3NHJWgFyGXqtyTohaN1ky8w",
  "logs": [
...
...
"extrinsics": [
    {
      "method": {
        "pallet": "timestamp",
        "method": "set"
      },
      "signature": null,
      "nonce": null,
      "args": {
        "now": "1728971508000"
      },
      "tip": null,
      "hash": "0xaa694d3b88f9611c63928912486dc9c474ef6122874ae41d64a71a899e9e3d21",
      "info": {},
      "era": {
        "immortalEra": "0x00"
      },
      "events": [
        {
          "method": {
            "pallet": "system",
            "method": "ExtrinsicSuccess"

It seems like this issue happened when your chain transitioned from metadata V14 to V15, introducing chain specific types. However, I think your team is better suited to explain what exactly changed and caused this issue.

Thanks for investigation, that works!

Adding here some of our findings from yesterday's debugging process in case it is helpful in the future for us or any other team.

This issue was very similar with the error posted from the Laos team in apps https://github.com/polkadot-js/apps/issues/10954 for the following reasons :

When connecting to Basilisk with apps we could see
```
PORTABLEREGISTRY: Unable to determine runtime Call type, cannot inspect sp_runtime::generic::unchecked_extrinsic::UncheckedExtrinsic
```
in the Console of Chrome Dev Tools. This was the same error that Laos mentioned here.
By looking at the error message returned, it mentions the signer and Unable to create Enum via index 124, in Id, Index, Raw, Address32, Address20 so the error might have been related to Accounts format like the Laos team identified here.
@bee344 correctly identified that the error starts when we start using pjs api v13.1.1 so making it very probable that the issue is related to the v15 metadata. The same conclusion was made by the Laos team here.
The fix from the Laos team can be seen in this PR based on the suggestion from @TarikGul here.
So it is probable that if Basilisk implemented a similar solution in their codebase, then maybe Sidecar could work without generating the Basilisk specific types bundle. A similar solution would be to move the apis implementations from api.rs to their lib.rs. However, I haven't tested this to verify that it actually works.
Another finding was related to the differences between v14 and v15 metadata. If we check the metadata endpoints in Sidecar while connected to Basilisk we can see that http://127.0.0.1:8080/runtime/metadata/v14 returns
```
{
"magicNumber": "1635018093",
"metadata": {
  "v14": {
    "lookup": {...}
     "pallets": [...]
     "extrinsic": {...}
     "type": "673"
}
```

and then if we request http://127.0.0.1:8080/runtime/metadata/v15 it returns

  {
    "magicNumber": "1635018093",
    "metadata": {
      "v15": {
        "lookup": {...}
         "pallets": [...]
         "extrinsic": {...}
         "type": "672"
         "apis": []
         "outerEnums": {...}
         "custom": {...}
  }

which shows that the apis item is an empty array which might be the cause of not being able to decode with V15.

Last, another observation was made from @bee344 when comparing metadata v14 vs v15 for Basilisk vs other chains. By checking the result of the calls Metadata.metadataAtVersion(14) and Metadata.metadataAtVersion(15) we see the following :

First bytes of Basilisk
- 0x74610e890a
- 0x74610f890a
First bytes of Kusama
- 0x74610f4510
- 0x74610e890e
For Basilisk, the only difference is the e to f that signals the change from v14 to v15
However, for other chains (relays or paras) there are 3 bytes that change, the version and two more. These 2 other bytes, we are not sure to what they correspond but they might be the cause of the decoding error.

paritytech / substrate-api-sidecar

Sidecar 19.2.2 fails to decode Basilisk block #1516