Beat [4/4]: implement Consumer in chainWatcher#9277
Conversation
|
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
d2b0ffa to
d863938
Compare
ac8ce82 to
a16b2d4
Compare
0ddd693 to
07631c0
Compare
c5f77e3 to
3456f2e
Compare
07631c0 to
96474de
Compare
3456f2e to
3d08b74
Compare
96474de to
c7747a2
Compare
3d08b74 to
e69cd41
Compare
c7747a2 to
a4f226a
Compare
e69cd41 to
cdd805f
Compare
a4f226a to
9f740cc
Compare
1e58126 to
abbee3b
Compare
9f740cc to
6bdb145
Compare
abbee3b to
aeafa63
Compare
0032fd7 to
5c9c6d0
Compare
29521a1 to
7b19d5c
Compare
5c9c6d0 to
54eaec8
Compare
a890230 to
0882921
Compare
|
|
||
| // If this is a taproot channel, before we proceed, we want to ensure | ||
| // that the expected funding output has confirmed on chain. | ||
| if c.cfg.chanState.IsPending && c.cfg.chanState.ChanType.IsTaproot() { |
There was a problem hiding this comment.
Posted the context in the other PR, not a bad idea to add more of that rationale here for future reviewers.
| } | ||
|
|
||
| // We have broadcast our commitment, and it is now confirmed onchain. | ||
| case closeInfo := <-c.cfg.ChainEvents.LocalUnilateralClosure: |
There was a problem hiding this comment.
Review note to make sure we remove the handling of these cases in the channelAttendant goroutine.
There was a problem hiding this comment.
So this is still here: we handle all these events in two locations now. IIUC, we only want to handle them when received by the block beat.
There was a problem hiding this comment.
At the bottom layer, we have two notifications,
RegisterBlockEpochNtfnwhich is the source of the block height used byblockbeat- ``RegisterSpendNtfn
which is the source of the funding spend used by thechainWatcher`
Observed from the itests, there is no gurantee of the event orders here - the chainWatcher may receive a blockbeat at height X, but only receives the spending notification at block X+1 or X-1, which means a close event may be sent from the chainWatcher to the ChannelArbitrator with one block offset, thus we need to catch the close event in two places - one in handleBlockbeat, in which we do a non-blocking read of the close event channels, and this should be most of the cases; the other one is done in channelAttendant, to catch the offset case to make sure we still process the close event.
Now, if the spending tx is notified at block X-1, we are fine as we want the close event to be there at block X. The bad case is the close event only arrives at block X+1, then we miss it at block X, which is why we added a change here 1200b75, where we always notify the spending tx before the block.
It doesn't completely solve the issue, as the above notification are sent in goroutines, and the receivers, aka subscribers, need to be aware of this possible race.
ziggie1984
left a comment
There was a problem hiding this comment.
Very close 👏
had some minor questions, PR looks dope 😺
| // As a height hint, we'll try to use the opening height, but if the | ||
| // channel isn't yet open, then we'll use the height it was broadcast | ||
| // at. This may be an unconfirmed zero-conf channel. | ||
| heightHint := chanState.ShortChanID().BlockHeight |
There was a problem hiding this comment.
hmm for zeroconf channel channels this might still be garbage data because the shortchanid is like a random alias (not super random but still).
also from the ShortChanID method:
// If IsZeroConf(), then this will the "base" (very first) ALIAS scid
// and the confirmed SCID will be stored in ConfirmedScid.
So I think we need to first theck for IsZeroConf first otherwise the blockeheight might not be 0 but wrong ?
There was a problem hiding this comment.
i think they are handled below?
There was a problem hiding this comment.
ahh gottya, kinda thought we are returning earlier. Maybe we cana structure the code so that if its zeroconf we fill out the chanID and return immediatly. and for the other case we proceed further. Otherwise we check the ShortChanID for zeroconf although it is not really needed.
|
|
||
| // If this is a taproot channel, before we proceed, we want to ensure | ||
| // that the expected funding output has confirmed on chain. | ||
| if c.cfg.chanState.IsPending && c.cfg.chanState.ChanType.IsTaproot() { |
| // TODO(Roasbeef): need to be able to ensure this only triggers | ||
| // on confirmation, to ensure if multiple txns are broadcast, we | ||
| // act on the one that's timestamped |
There was a problem hiding this comment.
cc @Roasbeef can you check if this TODO still needed here ?
|
|
||
| // Perform a non-blocking read on the close events in case the channel | ||
| // is closed in this blockbeat. | ||
| c.receiveAndProcessCloseEvent() |
There was a problem hiding this comment.
Should we maybe check if the state is already in contractClosed so there is no need to call this again ?
There was a problem hiding this comment.
yeah i like it, lemme try
There was a problem hiding this comment.
building in a side branch, will push once it passes all the tests
| } | ||
|
|
||
| // If this is a pending taproot channel, we need to register for a | ||
| // confirmation notification of the funding tx. |
There was a problem hiding this comment.
add a shorten explanation of the reasoning behind this as a comment from: https://github.com/lightningnetwork/lnd/pull/9277/files#r1864911793
There was a problem hiding this comment.
i think you are referencing the wrong place? this is about keysend cannot be recognized in RegisterSpend
0882921 to
4419530
Compare
This commit moves the creation of the spending notification from `Start` to `newChainWatcher` so we subscribe the spending event before handling the block, which is needed to properly handle the blockbeat.
To prepare for the blockbeat handler.
We now start notifying the blockbeat from the ChainArbitrator to the chainWatcher.
This commit adds the closing height to the logging and fixes a wrong height used in handling the breach event.
This commit adds a new method to enable us resending the blockbeat in `ChainArbitrator`, which is needed for the channel restore as the chain watcher and channel arbitrator are added after the start of the chain arbitrator.
To prepare the next commit where we would handle the event upon receiving a blockbeat.
6e3c1e4 to
d4baf58
Compare
4419530 to
0339e40
Compare
We need to check `dispatched` before sending conf details, otherwise the channel `ntfn.Event.Confirmed` will be blocking, which is the leftover from lightningnetwork#9275.
ziggie1984
left a comment
There was a problem hiding this comment.
LGTM 🧘♂️ - pending CI run
0339e40 to
03cb629
Compare
This is an oversight from addressing this commment: #9277 (comment) where we should focus on skipping the close events but not the resolvers.
This is an oversight from addressing this commment: lightningnetwork#9277 (comment) where we should focus on skipping the close events but not the resolvers.
This is an oversight from addressing this commment: lightningnetwork#9277 (comment) where we should focus on skipping the close events but not the resolvers.
This is an oversight from addressing this commment: #9277 (comment) where we should focus on skipping the close events but not the resolvers.
This is an oversight from addressing this commment: #9277 (comment) where we should focus on skipping the close events but not the resolvers.
This is an oversight from addressing this commment: #9277 (comment) where we should focus on skipping the close events but not the resolvers.
This PR implements the
Consumerinterface inchainWatcherwith necessary refactors.TODOs
Depends on
blockbeat#9276NOTE: itest is fixed in the final PR
This change is