-
Notifications
You must be signed in to change notification settings - Fork 406
Fix several more monitor-update-failed cases #288
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
Fix several more monitor-update-failed cases #288
Conversation
5e2f689
to
e9434de
Compare
Rebased after #284 merge. |
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.
Just a bunch of nits
src/ln/chanmon_update_fail_tests.rs
Outdated
|
||
// Queue up two payments - one will be delivered right away, one immediately goes into the | ||
// holding cell as nodes[0] is AwaitingRAA. Ultimately this allows us to deliver an RAA | ||
// immediately after a CS, meaning we deliver an RAA while the channel is in the |
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.
Hmm not super clear, "deliver an RAA from nodes[0] while the channel is in the monitor-update-failed on nodes[1] side which requires a CS response from this one to commit 2nd payment"
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.
Rewrote it, is it more clear now?
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.
Honestly, no. I mean I got it by reading the code, not with comment alone. Generally I find comments helpful when they precise at each message sender/receiver, so you get the whole interaction before to read code and then check if it match description. But don't care if you don't fix it go ahead to land monitor stuff
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.
Cool I rewrote it and added comments for each step. Hopefully that helps.
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.
Note that I'm moving the log entry additions to a later PR, but I did fix them so the changes will be reflected in that future PR. Also rebased on other PRs that will want to land first (as this is a file rename I'll wait a bit until we land some of the in-flight test PRs first, hopefully) and added another fix commit (probably one or two more coming).
src/ln/chanmon_update_fail_tests.rs
Outdated
|
||
// Queue up two payments - one will be delivered right away, one immediately goes into the | ||
// holding cell as nodes[0] is AwaitingRAA. Ultimately this allows us to deliver an RAA | ||
// immediately after a CS, meaning we deliver an RAA while the channel is in the |
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.
Rewrote it, is it more clear now?
e9434de
to
f99dc05
Compare
8e065a1
to
aec76b1
Compare
ac1508f
to
1348fa2
Compare
This fixes a rather subtle case handling RAAs when we don't generate a response due to a previous monitor update failure, but would otherwise send a CS response. We need to still set AwaitingRemoteRevoke on the channl in question, but previously did not. Found by chanmon_fail_consistency fuzz test with the failing test converted and added manually.
1348fa2
to
7dcd15e
Compare
7dcd15e
to
658e558
Compare
Gonna go ahead and take this since the first round of review was only nits. |
Based on #284 and #286, this splits up functional_tests into functional_test_utils, functional_tests, and chanmon_update_fail_tests. It then fixes one more (really subtle) case found by the new fuzzer I've been working on and adds some big log_trace output to buid_commitment_transaction.