-
Notifications
You must be signed in to change notification settings - Fork 684
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
Make pov-recovery ready for elastic scaling #3577
Comments
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 10, 2024
- unit tests for pov-recovery - elastic scaling support (recovering multiple candidates in a single relay chain block) - also some small cleanups - also switches to candidates_pending_availability in `handle_empty_block_announce_data` Fixes #3577 After #4097 is merged, we should also add a zombienet test, similar to the existing `0002-pov_recovery.toml` but which has a single collator using elastic scaling on multiple cores.
Ank4n
pushed a commit
that referenced
this issue
Jun 14, 2024
- unit tests for pov-recovery - elastic scaling support (recovering multiple candidates in a single relay chain block) - also some small cleanups - also switches to candidates_pending_availability in `handle_empty_block_announce_data` Fixes #3577 After #4097 is merged, we should also add a zombienet test, similar to the existing `0002-pov_recovery.toml` but which has a single collator using elastic scaling on multiple cores.
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this issue
Aug 2, 2024
…ch#4733) - unit tests for pov-recovery - elastic scaling support (recovering multiple candidates in a single relay chain block) - also some small cleanups - also switches to candidates_pending_availability in `handle_empty_block_announce_data` Fixes paritytech#3577 After paritytech#4097 is merged, we should also add a zombienet test, similar to the existing `0002-pov_recovery.toml` but which has a single collator using elastic scaling on multiple cores.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After #3576 is done, we should adjust the pov-recovery side.
The current logic logic assumes that we get at maximum one candidate per relay chain block, which gave us some nice ordering. With multiple pending candidates per relay chain block, we need to ensure the correct ordering. Other than that, the current logic should still work.
The text was updated successfully, but these errors were encountered: