Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime API: make backing_state return multiple candidates pending availability #3202

Closed
Tracked by #1829
alindima opened this issue Feb 5, 2024 · 3 comments · Fixed by #3479
Closed
Tracked by #1829

Runtime API: make backing_state return multiple candidates pending availability #3202

alindima opened this issue Feb 5, 2024 · 3 comments · Fixed by #3479
Assignees

Comments

@alindima
Copy link
Contributor

alindima commented Feb 5, 2024

This is being used by prospective-parachains when building fragment trees. Make the runtime API return an ordered collection of candidates pending availability for the given paraid.

@alindima
Copy link
Contributor Author

alindima commented Feb 5, 2024

the interface already supports this, just need to alter the implementation

@alindima
Copy link
Contributor Author

alindima commented Feb 5, 2024

The assumption that this returns an ordered collection of candidates is being made, for example here:

async fn preprocess_candidates_pending_availability<Context>(

@alindima alindima self-assigned this Feb 9, 2024
@alindima
Copy link
Contributor Author

on a second thought, this can't be done without #3131

@alindima alindima removed their assignment Feb 12, 2024
@alindima alindima linked a pull request Mar 15, 2024 that will close this issue
7 tasks
@alindima alindima self-assigned this Mar 15, 2024
github-merge-queue bot pushed a commit that referenced this issue Mar 21, 2024
Changes needed to implement the runtime part of elastic scaling:
#3131,
#3132,
#3202

Also fixes #3675

TODOs:

- [x] storage migration
- [x] optimise process_candidates from O(N^2)
- [x] drop backable candidates which form cycles
- [x] fix unit tests
- [x] add more unit tests
- [x] check the runtime APIs which use the pending availability storage.
We need to expose all of them, see
#3576
- [x] optimise the candidate selection. we're currently picking randomly
until we satisfy the weight limit. we need to be smart about not
breaking candidate chains while being fair to all paras -
#3573

Relies on the changes made in
#3233 in terms of the
inclusion policy and the candidate ordering

---------

Signed-off-by: alindima <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: eskimor <[email protected]>
dharjeezy pushed a commit to dharjeezy/polkadot-sdk that referenced this issue Mar 24, 2024
…h#3479)

Changes needed to implement the runtime part of elastic scaling:
paritytech#3131,
paritytech#3132,
paritytech#3202

Also fixes paritytech#3675

TODOs:

- [x] storage migration
- [x] optimise process_candidates from O(N^2)
- [x] drop backable candidates which form cycles
- [x] fix unit tests
- [x] add more unit tests
- [x] check the runtime APIs which use the pending availability storage.
We need to expose all of them, see
paritytech#3576
- [x] optimise the candidate selection. we're currently picking randomly
until we satisfy the weight limit. we need to be smart about not
breaking candidate chains while being fair to all paras -
paritytech#3573

Relies on the changes made in
paritytech#3233 in terms of the
inclusion policy and the candidate ordering

---------

Signed-off-by: alindima <[email protected]>
Co-authored-by: command-bot <>
Co-authored-by: eskimor <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Completed
Development

Successfully merging a pull request may close this issue.

1 participant