gci: Timeout for `test_commit_crash_splice`

[vincenzopalazzo]

It is not the fist time in this cycle that I am see the following Ci failure

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=========================== short test summary info ============================
FAILED tests/test_splicing.py::test_splice_out
FAILED tests/test_splicing.py::test_commit_crash_splice - Failed: Timeout >1200.0s
ERROR tests/test_splicing.py::test_commit_crash_splice - ValueError: 
Node errors:
 - lightningd-2: had BROKEN messages
 - lightningd-2: Node exited with return code 1
Global errors:
= 2 failed, 100 passed, 566 skipped, 36 warnings, 1 error in 1680.41s (0:28:00) =

We should look into it

[cdecker]

According to my stats this particular test has a flakyness of: 97 / 596 = 16.27% (27 / 166 = 16.26% on `master). This is very high, and likely the result of a messed up assumption somewhere in the code. We should defintiely tackle this, disable the test for now, as its signal-to-noise ratio makes it absolutely unusable, and file an issue to track that we need to fix it.

[cdecker]

I transformed this issue into a tracking issue for this specific test and assigning @ddustin as the original author of the test to check it :-)

[cdecker]

Also, this being a tooling and internal issue, should not have a milestone attached, unless the assignee choses to work on this in time for the milestone. Since the feature freeze is today, it is pointless to assign the milestone, especially without an assignee. We keep on bumping issues and features from milestone to milestone, making it rather pointless.

If there is a milestone attached:

1. We need an assignee
2. The assignee needs to have chosen to work on the task for the specific milestone
3. No one else should touch the milestone without asking the assignee
4. Release captains may remove the milestone if the target is missed, and the assignee may re-tag the issue with a new milestone.

[vincenzopalazzo]

Yeah I agree @cdecker

This was in the milestone just because I needed to take a look before the release, due to that this is a bug and the feature freeze day does not take into count bug fixing.

But your analysis is was I was missing, so all good!

[ddustin]

Ah that's pretty bad! @vincenzopalazzo do you have a link to one of these failed runs?

[vincenzopalazzo]

No sorry, but if you scan the PR I am pretty sure that you will find them @ddustin

[cdecker]

I'll collect some runs demonstrating the issue and paste them here.