Weird metadata parsing issue on "create" (v7.6.1)

[monitz87]

Getting METADATA: Unknown types found, no types for Lookup336 on our custom chain

We have no type named Lookup336, of course

I'm absolutely willing to provide more information, but I don't know what is relevant in this context

[jacogr]

It actually may have that type - the Lookup<num> form refers to the types are named in the metadata, i.e. 336 is the type with id: 336 as identified in the metadata. (Not all types do end up human-readable names, i.e. if only used inside a struct, it may not be exposed, so the only name available could be Lookup<num>)

So the questions are -

1. what do you do when this happens
2. what does the types part of your metadata look like? (easiest is probably just dumping the parsed value as returned by the rpc metadata call)

[monitz87]

1. I don't understand the question
2. https://gist.github.com/monitz87/5928eb87165e49bec0c6de18abb2b476

The relevant type is

{
        "id": 336,
        "type": {
          "path": [
            "schnorrkel",
            "sign",
            "Signature"
          ],
          "params": [],
          "def": {
            "composite": {
              "fields": [
                {
                  "name": "R",
                  "type": 337,
                  "typeName": "CompressedRistretto",
                  "docs": []
                },
                {
                  "name": "s",
                  "type": 338,
                  "typeName": "Scalar",
                  "docs": []
                }
              ]
            }
          },
          "docs": []
        }
      }

It's the only one showing as "LookupX" in the input passed to validateTypes

[monitz87]

If possible, I'd like to understand why that specific type (and no other) reached that stage as Lookup in the validateTypes input

[jacogr]

Sure, so all types used by extrinsics/state, etc. are tried to be named. It is very possible that a unique name may not be extractable (in rare cares, not here).

So assuming 335 is one of those used in state/extrinsic via https://gist.github.com/monitz87/5928eb87165e49bec0c6de18abb2b476#file-types-json-L20488, and this type uses 336 internally. So when validating 335, it will try to resolve Lookup336 as well.

The log/warning was really incorrect, Lookup* should always be resolvable... unless you randomly make them up, then they could fail... So assuming you have 500 types, then Lookup1 - Lookup499 should always work, named or not, i.e. api.createType('Lookup256') should be valid and yield the correct type in this "I have 500 types" example.

[jacogr]

An example on Kusama -

console.log(
  JSON.stringify(
    api.createType('Lookup3').toHuman(),
    null,
    2
  )
)

yields -

{
  "nonce": "0",
  "consumers": "0",
  "providers": "0",
  "sufficients": "0",
  "data": {
    "free": "0",
    "reserved": "0",
    "miscFrozen": "0",
    "feeFrozen": "0"
  }
}

It is indeed the FrameSystemAccountInfo type as per the metadata & id, e.g. as per the TS defs (this is why the Lookup<num> always appears, i.e. it is an internal names alias for that id) -

/**
   * Lookup3: frame_system::AccountInfo<Index, pallet_balances::AccountData<Balance>>
   **/
  FrameSystemAccountInfo: {
    nonce: 'u32',
    consumers: 'u32',
    providers: 'u32',
    sufficients: 'u32',
    data: 'PalletBalancesAccountData'
  },

[monitz87]

Thanks for the info. I'm still not sure why that specific type (and no other) was left as Lookup336 instead of its actual name. What makes that one different?

[jacogr]

No idea. It is a case of stepping through with the metadata in-hand and seeing what it does. It could be because the reference to it is a single-field struct, so it gets swapped out. But honestly no idea.