-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Beat [4/4]: implement Consumer
in chainWatcher
#9277
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
contractcourt/chain_watcher.go
Outdated
|
||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review note to make sure we remove the handling of these cases in the channelAttendant
goroutine.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the bottom layer, we have two notifications,
RegisterBlockEpochNtfn
which is the source of the block height used byblockbeat
- ``RegisterSpendNtfn
which is the source of the funding spend used by the
chainWatcher`
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.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think they are handled below?
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.
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.
contractcourt/chain_watcher.go
Outdated
|
||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
response can be found here: #7346 (comment)
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @Roasbeef can you check if this TODO still needed here ?
@@ -2992,6 +2992,10 @@ func (c *ChannelArbitrator) handleBlockbeat(beat chainio.Blockbeat) error { | |||
// Notify we've processed the block. | |||
defer c.NotifyBlockProcessed(beat, nil) | |||
|
|||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah i like it, lemme try
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.
building in a side branch, will push once it passes all the tests
contractcourt/chain_watcher.go
Outdated
fundingSpendNtfn: spendNtfn, | ||
} | ||
|
||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think you are referencing the wrong place? this is about keysend cannot be recognized in RegisterSpend
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.
sorry correct: #7346 (comment)
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.
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 🧘♂️ - pending CI run
0339e40
to
03cb629
Compare
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 🧜🏼
542b9c6
into
lightningnetwork:yy-feature-blockbeat
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
Consumer
interface inchainWatcher
with necessary refactors.TODOs
Depends on
blockbeat
#9276NOTE: itest is fixed in the final PR
This change is