nomination-pools: allow pool-ids to be reused

[Doordashcon]

closes #12001

polkadot address: 12zsKEDVcHpKEWb99iFt3xrTCQQXZMu477nJQsTBBrof5k2h

[kianenigma]

Please include your address in all of your PRs ;)

[Doordashcon]

cc @kianenigma

I assume a separate benchmark case is not needed for _with_pool_id

[kianenigma]

cc @rossbulat

[Ank4n]

LGTM!

We should also make changes to the front-end to reclaim an old pool-id by default whenever possible.

Reposting this for visibility:

Thinking out loud, I believe it shouldn't be too hard to to keep track of all the pools that are destroyed and ready to be claimed. In that case we would not really need another fn create_with_pool_id. The existing fn create would first try to get the next_reclaimable_pool_id and if not available, increment pool_id.

With current solution, we might need to expose an api to the frontend client to query a reclaimable pool-id that it can then pass to create_with_pool_id, so we will end up needing to track them anyway.

[Doordashcon]

Thinking out loud, I believe it shouldn't be too hard to to keep track of all the pools that are destroyed and ready to be claimed. In that case we would not really need another fn create_with_pool_id. The existing fn create would first try to get the next_reclaimable_pool_id and if not available, increment pool_id. With current solution, we might need to expose an api to the frontend client to query a reclaimable pool-id that it can then pass to create_with_pool_id, so we will end up needing to track them anyway.

The next_reclaimable_pool_id would be a storage item, adding Id when pools are deleted and selectively removing entries when creating.

Interesting 🤔

[kianenigma]

Thinking out loud, I believe it shouldn't be too hard to to keep track of all the pools that are destroyed and ready to be claimed. In that case we would not really need another fn create_with_pool_id. The existing fn create would first try to get the next_reclaimable_pool_id and if not available, increment pool_id.

With current solution, we might need to expose an api to the frontend client to query a reclaimable pool-id that it can then pass to create_with_pool_id, so we will end up needing to track them anyway.

Not sure where this is coming from, but I really disagree with this. This is how you write normal applications, not blockchains. Blockchains are the laziest software ever written. If a problem can be solved outside of the runtime (except in rare exceptions), you let it be solved outside of the runtime.

In this case, it it trivial for a UI to scan the pool ids and find one that the user is interested in, and if so, trigger the right transaction.

Putting a lot of logic into the blockchain to handle next_reclaimable_pool_id is not the right direction at all, at least in my school of thought.

[kianenigma]

/tip small

[substrate-tip-bot[bot]]

@kianenigma A small tip was successfully submitted for Doordashcon (12zsKEDVcHpKEWb99iFt3xrTCQQXZMu477nJQsTBBrof5k2h on polkadot).

https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/treasury/tips

[kianenigma]

bot merge

[paritytech-processbot[bot]]

Waiting for commit status.

[paritytech-processbot[bot]]

Merge cancelled due to error. Error: Statuses failed for 268eb8f1e46f851ea8dbbc3be6f6879ae11f845a

[kianenigma]

bot merge