Delay session changes' effects on parachains by 1 block #1354
Conversation
rphmeier
added
B0-silent
drahnr
left a comment
drahnr
left a comment
There was a problem hiding this comment.
A few small nitpicks.
For next and previous, I'd be in favor of introducing free floating single char variables n to clarify sequence relations i.e. for blocks or session indices, it makes reading lighter.
| // buffered session changes along with the block number at which they should be applied. | ||
| // | ||
| // typically this will be empty or one element long. ordered ascending by BlockNumber and insertion | ||
| // order. |
There was a problem hiding this comment.
what could cause this to be longer than 1 element?
There was a problem hiding this comment.
Multiple session-change notifications within a single block or a session change notification after initialization in block X and before initialization in child(X). The latter is more likely in practice, if you have a runtime upgrade that changes module order, but both cases would require a session that is only one block long (very very unlikely in practice)
There was a problem hiding this comment.
Oh and Governance as mentioned elsewhere
Co-authored-by: Bernhard Schuster <[email protected]>
|
I'm not sure why CI is failing in a different crate than I've even touched. Hopefully merging master will fix that. |
coriolinus
left a comment
coriolinus
left a comment
There was a problem hiding this comment.
Seems perfectly plausible to me.
| validators: I, | ||
| queued: Option<I>, | ||
| ) | ||
| where I: Iterator<Item=(&'a T::AccountId, ValidatorId)> |
There was a problem hiding this comment.
It may not matter, but IntoIterator bounds are sometimes more convenient than Iterator bounds.
rphmeier
added
A8-mergeoncegreen
and removed
A0-please_review
Closes #1327
This ensures that the validator-set who is responsible for parachain-related items included in a block can be deterministically derived from the relay-parent hash.