-
Notifications
You must be signed in to change notification settings - Fork 131
Relay basic single-bit message dispatch results back to the source chain #935
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
Changes from 1 commit
f7171f1
61ec89e
2110b9a
7377557
b43bc21
71be9ed
bd88510
15b3acf
d231c82
858e170
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -141,7 +141,7 @@ pub trait OnMessagesDelivered { | |
| /// Called when we receive confirmation that our messages have been delivered to the | ||
| /// target chain. The confirmation aso has single bit dispatch result for every | ||
| /// confirmed message (see `DeliveredMessages` for details). | ||
| fn on_messages_delivered(_messages: &DeliveredMessages) {} | ||
| fn on_messages_delivered(_lane: &LaneId, _messages: &DeliveredMessages) {} | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This'll need to do something with weights - I'm not yet sure how to deal with this. Change benchmarks to worst-case result and then refund? But what is worst case when there are e.g. multiple apps using different lanes for their purposes. And because of refund policy we'll need to decrease max number of messages in the confirmation tx. Probably just reserve single read and single write for the every registered callback? I'm not yet sure - will leave it for future PRs as well
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I think the general sentiment about these kind of handlers is that they should be as simple as possible. Having one read + one write seems reasonable. In future we can prepare some tooling to kind of "subscribe" to interesting messages and for instance have them processed in Might be good to add this assumption to the docs though, so that implementers are aware of that.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
| } | ||
|
|
||
| /// Structure that may be used in place of `TargetHeaderChain`, `LaneMessageVerifier` and | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.