-
Notifications
You must be signed in to change notification settings - Fork 385
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
Allow responding asynchronously to OnionMessage #2996
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2996 +/- ##
==========================================
- Coverage 89.90% 89.87% -0.03%
==========================================
Files 117 117
Lines 97105 97257 +152
Branches 97105 97257 +152
==========================================
+ Hits 87300 87412 +112
- Misses 7245 7275 +30
- Partials 2560 2570 +10 ☔ View full report in Codecov by Sentry. |
Updated from pr2996.01 to pr2996.02 (diff): Update:
|
cc @jkczyz, @TheBlueMatt |
Updated from pr2996.03 to pr2996.04 (diff): Updates:
|
Updated from pr2996.04 to pr2996.05 (diff): Updates:
|
Updated from pr2996.05 to pr2996.06 (diff): Updates:
|
Updated from pr2996.07 to pr2996.08 (diff): Changes:
|
Updated from pr2996.09 to pr2996.10 (diff): Changes:
|
Updated from pr2996.13 to pr2996.14 (diff): Changes:
|
Updated from pr2996.14 to pr2996.15 (diff): Changes:
|
@jkczyz, @TheBlueMatt |
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.
LGTM other than expanding the docs a bit.
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.
BTW, please avoid rebasing mid-review as it makes it difficult for reviewers to tell what has changed.
…st coverage This commit modifies handle_onion_message_response to be accessible publicly as handle_onion_message, enabling users to respond asynchronously. Additionally, a new test is introduced to validate this functionality.
And expand handle_onion_message_response return Type 1. Introduce a new function in OnionMessenger to create blinded paths. 2. Use it in handle_onion_message_response to create a reply_path for the right variant and use it in onion_message. 3. Expand the return type of handle_onion_message_response to handle three cases: 1. Ok(None) in case of no response to be sent. 2. Ok(Some(SendSuccess) and Err(SendError) in case of successful and unsuccessful queueing up of response messages respectively. This allows the user to get access to the Success/Failure status of the sending of response and handle it accordingly.
1. These two variants will be modified in an upcoming commit to be each other's response. 2. The names are updated to better fit their new roles.
- Introduce a new struct for keeping expectations organized. - Add a boolean field to track whether a response is expected, and hence whether a `reply_path` should be included with the response. - Update Ping and Pong roles for bidirectional communication. - Introduce panic for when there is no responder and we were expecting to include a `reply_path`. - Refactor `handle_custom_message` code.
- The new tests check both successful and unsuccessful `reply_path` creation conditions.
Updated from pr2996.18 to pr2996.19 (diff): Changes:
Understood! I tried to keep the changes with rebase separate, but for this one, I took a shortcut since the suggestion was a small one. I can see how that would have made reviewing difficult. I’ll make sure to keep the rebase and changes separate in the future. Thanks! |
|
||
let response = match msg { | ||
TestCustomMessage::Ping => TestCustomMessage::Pong, | ||
TestCustomMessage::Pong => TestCustomMessage::Ping, |
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.
Why are we responding to a pong with a ping? Shouldn't we fail if we are expected to reply to a Pong instead?
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.
The new test for this PR required multiple back-and-forth communication between the nodes. To allow doing so we settled on making Ping and Pong each other's response.
Here's a discussion thread related to it!
Thanks!
This PR addresses second part of #2882 and builds on #2907
This PR converts
handle_onion_message_response
into the public function which can be used for asynchronous response to a separately created ResponseInstruction.Also, this introduces a new variant of ResponseInstruction. This allows creating a reply_path for the receiver while responding to their message.