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

EXPERIMENTAL support for option_shutdown_anysegwit #4391

Merged

Conversation

rustyrussell
Copy link
Contributor

@rustyrussell rustyrussell commented Feb 19, 2021

See lightning/bolts#672

Changelog-None: Experimental only

The spec doesn't say to do this, but it makes sense, otherwise
they'll never be able to mutually close the channel.

Signed-off-by: Rusty Russell <[email protected]>
@cdecker
Copy link
Member

cdecker commented Feb 24, 2021

Code looks good, CI had a timeout, restarted 👍

ACK bbe17fc

It's timing out, even though we disable valgrind.

Signed-off-by: Rusty Russell <[email protected]>
@cdecker
Copy link
Member

cdecker commented Feb 25, 2021

It's timing out, even though we disable valgrind.

Ouch, I must've missed that exception (slow_test -> valgrind=False) going in, otherwise I'd have objected to it: this is actively harmful, since it suggests we are running with valgrind and that we'd be catching any memleak or invalid access, when in reality we have sneakily disabled valgrind for the test.

We are already testing without valgrind in another configuration, so there is no added value by just letting it run and pretend to be a valgrind test in this config. This test should just be marked as disabled under valgrind.

cdecker added a commit to cdecker/lightning that referenced this pull request Feb 26, 2021
Reviewing ElementsProject#4391 I noticed that we have a sneaky way of opting out of
valgrind using the `slow_test` marker. I consider this dangerous as it
causes a false sense of security ("this test is being run under
valgrind" when really it isn't), as exemplified by some of the tests
even branching on whether we run under valgrind or not.

This is my attempt of making tests explicitly opt out of valgrind
testing via the `@unittest.skipIf` decorator, which is more honest, as
it doesn't run the test in a tweaked configuration, and reports a
skipped test. The tests are all already being run on CI without
valgrind, so we don't lose any coverage by this, but are more
respectful of the resources we have on CI.
cdecker added a commit to cdecker/lightning that referenced this pull request Feb 26, 2021
Reviewing ElementsProject#4391 I noticed that we have a sneaky way of opting out of
valgrind using the `slow_test` marker. I consider this dangerous as it
causes a false sense of security ("this test is being run under
valgrind" when really it isn't), as exemplified by some of the tests
even branching on whether we run under valgrind or not.

This is my attempt of making tests explicitly opt out of valgrind
testing via the `@unittest.skipIf` decorator, which is more honest, as
it doesn't run the test in a tweaked configuration, and reports a
skipped test. The tests are all already being run on CI without
valgrind, so we don't lose any coverage by this, but are more
respectful of the resources we have on CI.
@rustyrussell
Copy link
Contributor Author

Ack 5905b53

(Since the slow_test changes are a separate issue)

@rustyrussell rustyrussell merged commit 48e91da into ElementsProject:master Mar 2, 2021
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.

2 participants