Dropdown oddity

[gilescope]

This is a really strange one. I have tested it on multiple machines and multiple browsers. I'm testing the latest version of kusama.

On the create an extrinsic screen, only when I run kusama locally, if I select any of the following pallets then the UI locks up as soon as I try and select a method (semantic ui Dropdown):

• council,
• multisig,
• proxy,
• recovery,
• scheduler,
• sudo,
• technicalCommittee,
• utility.

I think something in the creation of these pallets is causing react to have an infinite loop on the setState. I.e. I think somehow the setting of the state is dirtying something so it has to do it again or some such.

I tried it with 6 months+ old versions of polkadot-js and the same thing happens... so that sorta puts polkadot-js in the clear. I thought I'd put it out there in case any others have noticed the same at all - or if anyone has any inspiration about how this set of pallets are linked. This is an Agather Christie whodunit. Can anyone join the dots?

[gilescope]

When I built v0.9.27 it was fine locally, but not when I build 0.9.31 locally (fast-sudo branches). And yet the official polkadot release of 0.9.31 does work (because sudo wasn't in there).

UPDATE: v0.9.29 works. v0.9.30 does not, so something in v0.9.30 is annoying the UI in certain circumstances.

[gilescope]

It seems that only when I add in the sudo pallet does the UI start going wrong. It's set for pallet number 255.

[gilescope]

Ok so same binary is fine in kumulus with no sudo and fails with polkadot runtime with sudo. I'm adding sudo like this paritytech/polkadot@f641dbd#diff-e5e76e02c0d16e79c70b024cbe3c6ea56f3249382a0f987ba203c34fcb40ed66L1467

Why it causes other pallets to fail to be selected is a mystery. I tried using 45 instead of 255 as the pallet index and that still seem to didn't work.

[gilescope]

One big change between 29 and 30 is the way that the sudo pallet was added in. Possibly there's a difference between my and nacho's adding of the pallet that was fine for integration tests but not enough for polkadot-js? Will check that lead next.

[gilescope]

Ok so the root cause is that the construct_runtime macro doesn't honor the pallet order specified (enough). As such it makes a difference if the 255 sudo pallet is specified first in the construct_runtime macro or at the end. If it's first then the UI has this dropdown oddity behavior. I think the right fix is that regardless of the placing in construct_runtime, construct_runtime should produce the same code ordered by pallet id.

[jacogr]

The JS api strictly works on the index as supplied by the metadata (Obviously only older metadata versions < v12, it would strictly work on the order, there are no indexes)

If there is an oddity where indexes may not be useful, well, then I guess there needs to be a workaround. We are certainly not going to re-check the indexes and fallback to something else like counting the order. (This would lead to uncertainty and most certainly areas for bugs)

TL;DR Don't see this as API related which does the correct thing, following the indexes as supplied in the metadata. Closing.

[polkadot-js-bot]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.