channeldb/db: prevent filtering channels with unconfirmed close txs #2248
Conversation
channeldb/db.go
Outdated
| @@ -511,7 +511,7 @@ func fetchChannels(d *DB, pending, waitingClose bool) ([]*OpenChannel, error) { | |||
| "node_key=%x: %v", chainHash[:], k, err) | |||
| } | |||
| for _, channel := range nodeChans { | |||
| if channel.IsPending != pending { | |||
| if !waitingClose && channel.IsPending != pending { | |||
There was a problem hiding this comment.
Hmm.. this code is not straight forward to follow. Would it be better to instead add the channel if either
channel.IsPending == pendingchannelWaitingClose == waitingClose
Another option is to only consider the pending argument if it is true, and use both pending and waitingClose as a way of filter channels.
There was a problem hiding this comment.
I'm not sure either is equivalent to the new behavior? Switching from 1 && 2 to 1 || 2 doesn't offer enough constraint to target a single quadrant of the state space. The new behavior ignores pending if we are looking for waitingClose=true channels, which is not the same as only considering pending if pending=true.
Docs + comments would help out here for sure
There was a problem hiding this comment.
yeah, but with this ther will also be a quadrant impossible to target? (1 && 2)
There was a problem hiding this comment.
The simplest change (the one proposed) is to treat channels that are pending and waiting close as waiting close, so it’s collapsing the two quadrants where waiting close is true.
We could leave the filtering logic as is, and just query for (pending=true, waitingClose=true) and (pending=false, waitingClose=true) and combine the results, which would be equivalent
There was a problem hiding this comment.
Indeed, I think that keeps the filtering logic clearer
cc @wpaulino
Roasbeef
added
database
|
Ping! |
…annels In this commit, we use random outpoints when creating new test channels to ensure we can uniquely identify them.
In this commit, we add a test case for FetchWaitingCloseChannels to ensure it behaves as intended. Currently, this test fails due to not fetching channels which are pending to be closed but are also pending to be opened. This will be fixed in the following commit and should allow the test to pass.
In this commit, we address an issue with the FetchWaitingCloseChannels method where it would not properly return channels that are unconfirmed and also have an unconfirmed closing transaction because they were filtered out. We fix this by fetching channels that remain unconfirmed that are also waiting for a confirmed closing transaction. This will allow the recently added test TestFetchWaitingCloseChannels to pass.
| @@ -852,6 +852,79 @@ func TestFetchClosedChannels(t *testing.T) { | |||
| } | |||
| } | |||
|
|
|||
| // TestFetchWaitingCloseChannels ensures that the correct channels that are | |||
| // waiting to be closed are returned. | |||
| func TestFetchWaitingCloseChannels(t *testing.T) { | |||
There was a problem hiding this comment.
Generally, the fixing commit should be added before the test case, to ensure the commit history is always building/passing. Not a blocker for this PR tho.
In this commit, we address an issue with the FetchWaitingCloseChannels
method where it would not properly return channels that are unconfirmed
and also have an unconfirmed closing transaction because they were
filtered out. We fix this by modifying the filtering logic to only apply
when the channel has already confirmed.
Related to #2217.