Skip to content
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

channeldb/db: prevent filtering channels with unconfirmed close txs #2248

Merged

Conversation

@wpaulino
Copy link
Collaborator

@wpaulino wpaulino commented Nov 30, 2018

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.

Copy link
Collaborator

@cfromknecht cfromknecht left a comment

LGTM

@wpaulino wpaulino force-pushed the wpaulino:fetch-waiting-close-channels branch from 560faf0 to 75b529f Nov 30, 2018
Copy link
Collaborator

@cfromknecht cfromknecht left a comment

LGTM

@@ -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 {

This comment has been minimized.

@halseth

halseth Dec 3, 2018
Collaborator

Hmm.. this code is not straight forward to follow. Would it be better to instead add the channel if either

  1. channel.IsPending == pending
  2. channelWaitingClose == 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.

This comment has been minimized.

@cfromknecht

cfromknecht Dec 4, 2018
Collaborator

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

This comment has been minimized.

@halseth

halseth Dec 4, 2018
Collaborator

yeah, but with this ther will also be a quadrant impossible to target? (1 && 2)

This comment has been minimized.

@cfromknecht

cfromknecht Dec 4, 2018
Collaborator

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

This comment has been minimized.

@halseth

halseth Dec 4, 2018
Collaborator

Latter suggestion SGTM :)

This comment has been minimized.

@cfromknecht

cfromknecht Dec 6, 2018
Collaborator

Indeed, I think that keeps the filtering logic clearer
cc @wpaulino

This comment has been minimized.

@wpaulino

wpaulino Dec 11, 2018
Author Collaborator

Fixed.

@wpaulino wpaulino force-pushed the wpaulino:fetch-waiting-close-channels branch 2 times, most recently from 03fcd7f to 346bb1d Dec 11, 2018
@Roasbeef Roasbeef added this to In progress in High Priority via automation Dec 18, 2018
@Roasbeef Roasbeef moved this from In progress to Needs review in High Priority Dec 18, 2018
Copy link
Member

@Roasbeef Roasbeef left a comment

Should be accompanied by a basic test to demonstrate the prior blind case (test fails on master right now) and ensure this change fixes it. Other than that, modified logic is straight forward.

@Roasbeef
Copy link
Member

@Roasbeef Roasbeef commented Jan 3, 2019

Ping!

Copy link
Collaborator

@halseth halseth left a comment

LGTM after test addition!

…annels

In this commit, we use random outpoints when creating new test channels
to ensure we can uniquely identify them.
@wpaulino wpaulino force-pushed the wpaulino:fetch-waiting-close-channels branch 2 times, most recently from 864cc8c to 70a917d Jan 4, 2019
wpaulino added 2 commits Jan 4, 2019
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.
@wpaulino wpaulino force-pushed the wpaulino:fetch-waiting-close-channels branch from 70a917d to 70d3fc6 Jan 4, 2019
@wpaulino
Copy link
Collaborator Author

@wpaulino wpaulino commented Jan 4, 2019

@Roasbeef @halseth test added!

@halseth
halseth approved these changes Jan 4, 2019
Copy link
Collaborator

@halseth halseth left a comment

LGTM!

@@ -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) {

This comment has been minimized.

@halseth

halseth Jan 4, 2019
Collaborator

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.

Copy link
Member

@Roasbeef Roasbeef left a comment

LGTM 🌦

High Priority automation moved this from Needs review to Final Testing -- Ready For Merge Jan 4, 2019
@Roasbeef Roasbeef merged commit 6787ba2 into lightningnetwork:master Jan 4, 2019
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.04%) to 55.958%
Details
High Priority automation moved this from Final Testing -- Ready For Merge to Done Jan 4, 2019
@wpaulino wpaulino deleted the wpaulino:fetch-waiting-close-channels branch Jan 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
High Priority
  
Done
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants