-
Notifications
You must be signed in to change notification settings - Fork 407
Make ChannelMonitor aware of counterparty's node id #1596
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
Make ChannelMonitor aware of counterparty's node id #1596
Conversation
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.
I don't see why this needs to be an update - it doesn't change through the lifetime of the channel, just give the channelmonitor the counterparty's node id when its first created.
ad4fba9
to
c65f150
Compare
Codecov Report
@@ Coverage Diff @@
## main #1596 +/- ##
==========================================
+ Coverage 91.07% 91.11% +0.04%
==========================================
Files 80 80
Lines 44128 44876 +748
Branches 44128 44876 +748
==========================================
+ Hits 40190 40890 +700
- Misses 3938 3986 +48
Continue to review full report at Codecov.
|
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.
c65f150
to
e5b3b64
Compare
e5b3b64
to
2d49336
Compare
@TheBlueMatt saw that I used a type number that is not consistent in read/write_tlv_fields, so I fixed that and repushed |
Could you update the commit message / PR description for the reason for this change? |
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.
ACK 2d4933
@jkczyz done :) |
FWIW, I'd much rather motivation be in commit descriptions than github. Ideally the git history should stand by itself without cross-referencing github for motivation for things. In this case, though, motivation is pretty trivial :) |
@TheBlueMatt gotcha, my apologies. Will note that for next time :) |
In #1403, we want to be able to send an
HTLCHandlingFailed
event, which has an enum field,next_hop_destination: HTLCDestination
, that defines the reason for the error.One of the variants is
HTLCDestination::NextHopChannel
, which describes the scenario where we tried forwarding to a channel but failed to do so.When processing a channel monitor's events, we can possibly run into a scenario where we are unable to process an HTLC because the channel has closed.
ChannelManager
will also not be aware of the channel as a result, and we will not be able to look it up to say who the HTLC was meant for.Therefore, the only way to define the channel counterparty in
HTLCDestination::NextHopChannel
is by makingChannelMonitor
aware ofcounterparty_node_id
, and piping it throughMonitorEvent
for it to be used.Related discussion: #1403 (comment)