Skip to content

close: change parameters, defaults#2914

Merged
rustyrussell merged 3 commits into
ElementsProject:masterfrom
rustyrussell:guilt/close-48-hrs-force
Aug 9, 2019
Merged

close: change parameters, defaults#2914
rustyrussell merged 3 commits into
ElementsProject:masterfrom
rustyrussell:guilt/close-48-hrs-force

Conversation

@rustyrussell
Copy link
Copy Markdown
Contributor

Fixes: #2791

Painful transition, but I think a long-term win for sane defaults.

We're about to change the API, so this makes the tests still work
across the transition (and, as a bonus, tests our backwards compat
shim).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Comment thread doc/lightning-close.7.txt Outdated
Comment thread tests/test_closing.py Outdated
@@ -241,7 +240,7 @@ def test_closing_different_fees(node_factory, bitcoind, executor):
# so increase the timeout so that this test will pass
# when valgrind is enabled.
# (close timeout defaults to 30 as of this writing)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe change the comment as well?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, changed the arg to 0, so it's infinite and no unilateral.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Latest commit-set seems to have skipped this use of close entirely?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it eliminates it?

-    # Now close all channels
-    # All closes occur in parallel, and on Travis,
-    # ALL those lightningd are running on a single core,
-    # so increase the timeout so that this test will pass
-    # when valgrind is enabled.
-    # (close timeout defaults to 30 as of this writing)
-    closes = [executor.submit(l1.rpc.close, p.channel, False, 90) for p in peers]
+    # Now close all channels (not unilaterally!)
+    closes = [executor.submit(l1.rpc.close, p.channel, 0) for p in peers]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, must have been some weirdness in github then. Okay.

Comment thread tests/test_closing.py
`close` takes two optional arguments: `force` and `timeout`.
`timeout` doesn't timeout the close (there's no way to do that), just
the JSON call.  `force` (default `false`) if set, means we unilaterally
close at the timeout, instead of just failing.

Timing out JSON calls is generally deprecated: that's the job of the
client.  And the semantics of this are confusing, even to me!  A
better API is a timeout which, if non-zero, is the time at which we
give up and unilaterally close.

The transition code is awkward, but we'll manage for the three
releases until we can remove it.

The new defaults are to unilaterally close after 48 hours.

Fixes: ElementsProject#2791
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@rustyrussell rustyrussell force-pushed the guilt/close-48-hrs-force branch from 370cf3b to e7748a6 Compare August 8, 2019 06:48
Only downside is you have to wait 1 second at least before
unilaterally closing.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@rustyrussell rustyrussell force-pushed the guilt/close-48-hrs-force branch from e7748a6 to 849e636 Compare August 8, 2019 06:48
@rustyrussell rustyrussell merged commit 0edc0ae into ElementsProject:master Aug 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

close should force by default, increase timeout to 48 hours?

2 participants