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.

Sign up for GitHub

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

Jump to bottom

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
@alindima

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 alindima mentioned this issue Feb 5, 2024
Open
@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:

polkadot-sdk/polkadot/node/core/prospective-parachains/src/lib.rs

Line 354 in 53f615d

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 mentioned this issue Feb 26, 2024
Merged
7 tasks
@alindima alindima linked a pull request Mar 15, 2024 that will close this issue
Elastic scaling: runtime dependency tracking and enactment #3479
Merged
7 tasks
@alindima alindima moved this from Backlog to In Progress in parachains team board Mar 15, 2024
@alindima alindima self-assigned this Mar 15, 2024
@alindima alindima moved this from In Progress to Review in progress in parachains team board Mar 20, 2024
github-merge-queue bot pushed a commit that referenced this issue Mar 21, 2024
@alindima @eskimor
Elastic scaling: runtime dependency tracking and enactment (#3479)
4842faf 
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 <alin@parity.io>
Co-authored-by: command-bot <>
Co-authored-by: eskimor <eskimor@users.noreply.github.com>
@github-project-automation github-project-automation bot moved this from Review in progress to Completed in parachains team board Mar 21, 2024
dharjeezy pushed a commit to dharjeezy/polkadot-sdk that referenced this issue Mar 24, 2024
@alindima @eskimor @dharjeezy
Elastic scaling: runtime dependency tracking and enactment (paritytec…
82aafe7 
…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 <alin@parity.io>
Co-authored-by: command-bot <>
Co-authored-by: eskimor <eskimor@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@alindima alindima

Labels
None yet
Projects
parachains team board
Status: Completed
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Elastic scaling: runtime dependency tracking and enactment paritytech/polkadot-sdk
1 participant
@alindima