-
Notifications
You must be signed in to change notification settings - Fork 400
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
Followups to #3125 #3145
Followups to #3125 #3145
Conversation
Fuzzers should always do more, not less. Post-merge feedback on e8f154d.
Dummy implementation for now. This avoids having to change a bunch of type signatures in the future when we replace the dummy impl with a real one.
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 #3145 +/- ##
==========================================
- Coverage 89.83% 89.76% -0.08%
==========================================
Files 121 121
Lines 98900 98909 +9
Branches 98900 98909 +9
==========================================
- Hits 88847 88785 -62
- Misses 7457 7522 +65
- Partials 2596 2602 +6 ☔ View full report in Codecov by Sentry. |
let responder = match responder { | ||
Some(resp) => resp, | ||
None => return ResponseInstruction::NoResponse, | ||
}; |
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.
Man that's an annoying amount of boilerplate to respond...
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.
We could change the interface to not use an Option
if we always expect a reply path.
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.
Then we'd have to drop messages that are missing a reply_path? I guess we could but that seems weird to do at the OnionMessenger
level. We could consider a responder that is incapable of responding (with some kind of alternative name for the struct?), but that's definitely out of scope for this PR.
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.
Yeah, though it could be done a handler-by-handler basis
d43218a
into
lightningdevkit:main
See #3125 (comment) and below.