This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Implementer's Guide: Make HRMP use upward message kinds #1591
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pepyakin
added
A0-please_review
Pull request needs code review.
B0-silent
Changes should not be mentioned in any release notes
C1-low
PR touches the given topic and has a low impact on builders.
labels
Aug 14, 2020
drahnr
reviewed
Aug 17, 2020
Co-authored-by: Bernhard Schuster <bernhard@ahoi.io>
drahnr
reviewed
Aug 17, 2020
/// Used for checking if a given channel is registered for closure. | ||
/// | ||
/// The set is accompanied by a list for iteration. | ||
/// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 explicitness
drahnr
reviewed
Aug 17, 2020
drahnr
approved these changes
Aug 17, 2020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few very minor nits, other than that - LGTM!
Co-authored-by: Bernhard Schuster <bernhard@ahoi.io>
drahnr
reviewed
Aug 17, 2020
rphmeier
reviewed
Aug 17, 2020
/// Invariant: | ||
/// - There are no channels that exists in list but not in the set and vice versa. | ||
HrmpOpenChannelRequests: map HrmpChannelId => Option<HrmpOpenChannelRequest>; | ||
HrmpOpenChannelRequestsList: Vec<HrmpChannelId>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
frame
maps support iteration already, i believe.
rphmeier
reviewed
Aug 17, 2020
Co-authored-by: Robert Habermeier <rphmeier@gmail.com>
rphmeier
approved these changes
Aug 17, 2020
ordian
added a commit
that referenced
this pull request
Aug 20, 2020
* master: Companion for Substrate #6815 (Dynamic Whitelist) (#1612) Candidate backing respects scheduled collator (#1613) implementers-guide: in TOC move collators before backing, to match protocol pipeline (#1611) Initial guide text for approvals and especially approvals assignments (#1518) Implement validation data refactor (#1585) Implementer's Guide: Make HRMP use upward message kinds (#1591)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
A0-please_review
Pull request needs code review.
B0-silent
Changes should not be mentioned in any release notes
C1-low
PR touches the given topic and has a low impact on builders.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR changes HRMP so that it uses upward message kinds that were introduced in #1556 for channel opening and closing channels.
We also drop the notion of initiator because it is not used. To support requests for governance or retiring HRMP we introduce another queue which will be processed during the session change.
This PR doesn't update the
TransientValidationData
yet in spirit of #1539 since it would inflate it. I wonder if we could changeTransientValidationData
to something that won't require us assembling a lot of data.