Closed ziggie1984 closed 6 days ago
[!IMPORTANT]
Review skipped
Auto reviews are limited to specific labels.
:label: Labels to auto review (1)
* llm-reviewPlease check the settings in the CodeRabbit UI or the
.coderabbit.yaml
file in this repository. To trigger a single review, invoke the@coderabbitai review
command.You can disable this status message by setting the
reviews.review_status
tofalse
in the CodeRabbit configuration file.
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?
Ok I think this approach is not really good because you were raising a really good point here @guggero:
go func(arb *ChannelArbitrator) {
defer wgChannelArb.Done()
select {
case channelArbErrs <- arb.Start(startState):
case <-ctx.Done():
channelArbErrs <- ctx.Err()
case <-c.quit:
channelArbErrs <- ErrChainArbExiting
}
}(arbitrator)
This call does block forever when we launch the arb.Start
prior timeout, which we very likely will, the starting is not the problem but more the finishing.
Tho looking into the start() function I don't really see an easy way to spawn goroutines which could cancel because of a timeout. I think what we should garantee is, that the call to the external units should be timing out if the call blocks. So I think this change makes no real sense.
By easy way, I don't think it is appropriate design, cancels imo make only sense if we know we spawn goroutines in that function but our problem arises because a function call to a normal subsystem does not timeout, so I think we need to improve there.
what we could do which is the only way it could work is something like this:
// Create a new goroutine for the actual Start call
startErrChan := make(chan error, 1)
go func() {
startErrChan <- arb.Start(startState)
}()
// Wait for either the start to complete or context to be done
select {
case err := <-startErrChan:
channelArbErrs <- err
case <-ctx.Done():
// Don't wait for Start to complete if timeout occurs
channelArbErrs <- ctx.Err()
case <-c.quit:
channelArbErrs <- ErrChainArbExiting
basically starting a goroutine in a goroutine. Only then can we really abort after the timeout.
Ok I mean spawning goroutines might not be the best solution here because we need for each startup 2, but I implemented it nonetheless because maybe it will take a while until we have the hooks for external subsystems configurable with timeouts.
@Roasbeef this works as well and resolves the deadlock.
closing in favour of https://github.com/lightningnetwork/lnd/pull/9253
Followup of https://github.com/lightningnetwork/lnd/pull/9253. This makes sure we start the channel arbitrators concurrently with a maximum timeout of 5 min.