Merge collective data from multiple sources of members (collective + elections)

[arrudagates]

• I'm submitting a ...

• [x] Bug report
• [ ] Feature request
• [ ] Support request
• [ ] Other

• What is the current behavior and expected behavior? When the council pallet includes members from both elections and a separate source at the same time, apps just assumes only one must be the correct source, the moment an election candidate becomes a member, all other sources disappear and the UI gets confused about how many members there actually are. I found the issue to be in this section of this function, which is the source for this data in the apps UI: https://github.com/polkadot-js/api/blob/master/packages/api-derive/src/elections/info.ts#L116-L118

Expected behavior is that the UI should always prioritize the members list from the council collective pallet and not from elections, as the latter might not always be correct, and the storage in the collective pallet will always be. A merge of both should happen in this case so that the elected members display their backing in the UI and the separate source members display something else, maybe their source.

• What is the motivation for changing the behavior? It just shows wrong information when the pallets don't behave exactly like in the relays, this is not a modified council collective pallet, it's just being used in a different way other than what the apps UI is used to. This should be flexible and display the correct data regardless of how many sources of members are at play in the chain.

• Please tell us about your environment: The environment is not really relevant here, but the pallet structure of the chain is, the difference from the usual usage of the council collective pallet here is that the collective pallet has a max number of seats X, then pallet elections phragmen is one of the member sources, it has max candidates set to X / 2, and then there's also pallet membership which is also a source of members for the council and also has max candidates set to X / 2.

• Version: latest

• Environment:

  • [ ] Node.js
  • [x] Browser
  • [ ] Other (limited support for other environments)

• Language:

  • [ ] JavaScript
  • [ ] TypeScript (include tsc --version)
  • [ ] Other

[jacogr]

So, the UI is built around Kusama and Polkadot behavior - it is exceptionally difficult to add additional logic for how other chain may or may not use this. For each "special case" there is additional logic, which needs to be maintained. This is not a once-off cost, but rather an ongoing cost.

Since we are moving to Gov2 anyway and Gov1 will cease being in use, it also means spending effort on something that has a limited lifetime. So the logic is unlikely to change.

[arrudagates]

Alright, that's a really good point. I'd also like to ask that for gov2 these aspects should be taking into consideration from the get go, because like this issue, it can be made flexible without compromising the expected behavior from the relay chains.

[jacogr]

The code is written around what can be tested against deployed chains - I never try to over-engineer to guess how people may deploy the various pallets. There is x hours in a day, 7 days a week and a large lot of repos for the full polkadot-js that I'm covering alone in terms of coding, support and documentation, be it common libs, wasm bindings, JS api, ui components, extension, cli tools or the apps UI.

So happy to listen to suggestions, within reason, or even better, look at PRs than extends things into other directions.

[polkadot-js-bot]

This issue has been open for 21 days with no activity and is not labelled as an enhancement. It will be closed in 7 days.