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: make the candidate relay parent progression check more strict #5113

Merged
merged 5 commits into from
Jul 26, 2024

Conversation

alindima
Copy link
Contributor

@alindima alindima commented Jul 23, 2024

Previously, we were checking if the relay parent of a new candidate does not move backwards from the latest included on-chain candidate. This was fine prior to elastic scaling. We now need to also check that the relay parent progresses from the latest pending availability candidate, as well as check the progression within the candidate chain in the inherent data.

Prospective-parachains is already doing this check but we should also add it in the runtime

Previously, we were checking if the relay parent of a new candidate does not
move backwards from the latest included on-chain candidate.
This was fine prior to elastic scaling. We now need to also check
that the relay parent progresses from the latest pending availability candidate,
as well as check the progression within the candidate chain in the inherent data.
@alindima alindima added I2-bug The node fails to follow expected behavior. T8-polkadot This PR/Issue is related to/affects the Polkadot network. labels Jul 23, 2024
@paritytech-cicd-pr
Copy link

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-clippy
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6777748

Copy link
Member

@eskimor eskimor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good on a quick pass. Nice catch, thanks @alindima

Copy link
Contributor

@sandreim sandreim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch @alindima. LGTM!

@alindima alindima added this pull request to the merge queue Jul 23, 2024
@alindima alindima removed this pull request from the merge queue due to a manual request Jul 23, 2024
@eskimor eskimor added this pull request to the merge queue Jul 24, 2024
@alindima alindima removed this pull request from the merge queue due to a manual request Jul 24, 2024
@alindima alindima added this pull request to the merge queue Jul 26, 2024
Merged via the queue into master with commit fc07bda Jul 26, 2024
159 of 162 checks passed
@alindima alindima deleted the alindima/tighten-relay-parent-check branch July 26, 2024 13:39
alindima added a commit that referenced this pull request Jul 26, 2024
#5113)

Previously, we were checking if the relay parent of a new candidate does
not move backwards from the latest included on-chain candidate. This was
fine prior to elastic scaling. We now need to also check that the relay
parent progresses from the latest pending availability candidate, as
well as check the progression within the candidate chain in the inherent
data.

Prospective-parachains is already doing this check but we should also
add it in the runtime
alindima added a commit that referenced this pull request Jul 26, 2024
#5113)

Previously, we were checking if the relay parent of a new candidate does
not move backwards from the latest included on-chain candidate. This was
fine prior to elastic scaling. We now need to also check that the relay
parent progresses from the latest pending availability candidate, as
well as check the progression within the candidate chain in the inherent
data.

Prospective-parachains is already doing this check but we should also
add it in the runtime
bkchr pushed a commit that referenced this pull request Jul 26, 2024
…on check more strict (#5156)

Backports #5113 on top of
v1.14
bkchr pushed a commit that referenced this pull request Jul 26, 2024
…ssion check more stric… (#5157)

Backports #5113 on top of
stable2407
Morganamilo pushed a commit that referenced this pull request Jul 29, 2024
#5113)

Previously, we were checking if the relay parent of a new candidate does
not move backwards from the latest included on-chain candidate. This was
fine prior to elastic scaling. We now need to also check that the relay
parent progresses from the latest pending availability candidate, as
well as check the progression within the candidate chain in the inherent
data.

Prospective-parachains is already doing this check but we should also
add it in the runtime
TarekkMA pushed a commit to moonbeam-foundation/polkadot-sdk that referenced this pull request Aug 2, 2024
paritytech#5113)

Previously, we were checking if the relay parent of a new candidate does
not move backwards from the latest included on-chain candidate. This was
fine prior to elastic scaling. We now need to also check that the relay
parent progresses from the latest pending availability candidate, as
well as check the progression within the candidate chain in the inherent
data.

Prospective-parachains is already doing this check but we should also
add it in the runtime
fellowship-merge-bot bot added a commit to polkadot-fellows/runtimes that referenced this pull request Aug 5, 2024
<!-- Remember that you can run `/merge` to enable auto-merge in the PR
-->

<!-- Remember to modify the changelog. If you don't need to modify it,
you can check the following box.
Instead, if you have already modified it, simply delete the following
line. -->

Includes the following fix:
paritytech/polkadot-sdk#5113

- [x] Does not require a CHANGELOG entry

Co-authored-by: fellowship-merge-bot[bot] <151052383+fellowship-merge-bot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I2-bug The node fails to follow expected behavior. T8-polkadot This PR/Issue is related to/affects the Polkadot network.
Projects
Status: Completed
Development

Successfully merging this pull request may close these issues.

5 participants