Add new staging Runtime API: candidates_pending_availability
#3576
Assignees
Labels
T4-runtime_API
This PR/Issue is related to runtime APIs.
Comments
This was referenced Mar 5, 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 <alin@parity.io> Co-authored-by: command-bot <> Co-authored-by: eskimor <eskimor@users.noreply.github.com>
|
for prototyping, we could use the backing_state API for this. it's already returning the vector of candidates pending availability for that paraid. arguably, it's less performant because it also returns some Contraints, which includes xcm messages |
|
It includes the commitments for all candidates pending availabiliy anyway, so that can be pretty huge with code upgrade and all messages sent by the parachain. But yeah, it's good for the elastic scaling prototype. |
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 <alin@parity.io> Co-authored-by: command-bot <> Co-authored-by: eskimor <eskimor@users.noreply.github.com>
1 task
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 12, 2024
Fixes #3576 Required by elastic scaling collators. Deprecates old API: `candidate_pending_availability`. TODO: - [x] PRDoc --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is mandatory for elastic scaling support in Cumulus. This new API should obsolete the existing
candidate_pending_availabilityAPI which just returns the first candidate as per #3479 .Should work just like it's predecessor, but return all candidates pending availability:
fn candidates_pending_availability(para_id: ParaId) -> Vec<CommittedCandidateReceipt<Hash>>More context about usage in Cumulus:
handling handle_empty_block_announce_data)The text was updated successfully, but these errors were encountered: