pytest: fix timeout flake in test_dataloss_protection
What the developer wrote
Authored by Rusty Russell
pytest: fix timeout flake in test_dataloss_protection
This test restarts l2 twice. Each time, l1 is reconnecting, and backs
off. If the test is slow enough, the backoff gets extreme:
```
2026-02-19T02:13:03.7669982Z lightningd-1 2026-02-19T01:50:56.541Z DEBUG 033845802d25b4e074ccfd7cd8b339a41dc75bf9978a034800444b51d42b07799a-lightningd: peer_disconnected
2026-02-19T02:13:03.7670444Z lightningd-1 2026-02-19T01:50:56.547Z DEBUG 033845802d25b4e074ccfd7cd8b339a41dc75bf9978a034800444b51d42b07799a-connectd: Will try reconnect in 256 seconds
```
This isn't a bug! The backoff caps at 300 seconds, and only gets
reset if we remain connected for that long.
A manual reconnect here not only fixes the flake, but make the test
much faster, by not *doubling* the time for slow tests as shown on my
laptop (the final test using `taskset -c 1`):
Normal Valgrind Valgrind, 1 CPU
Before: 22sec 124sec 230sec
After: 18sec 102sec 191sec
These are from a single run: it could be much more in the worst case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This commit fixes a flaky automated test, not a security bug. The test was sometimes timing out because one node kept waiting longer and longer to reconnect after the other node restarted. The fix manually triggers a reconnect so the test completes faster and more reliably. There is no change to production code or user-facing behavior.
No security action required. Treat as a normal test reliability improvement.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch adds a single l1.rpc.connect(...) call in tests/test_connection.py::test_dataloss_protection. The test restarts l2 twice; each restart causes l1 to attempt reconnection with exponential backoff capped at 300 s. On slow CI runners the accumulated backoff could exceed the test timeout, producing a flake. The manual reconnect resets the connection attempt immediately, shortening runtime and avoiding the timeout. No daemon, protocol, or library code is modified.
Changed components
tests/test_connection.pyInspect captured patch +6 / −0
diff --git a/tests/test_connection.py b/tests/test_connection.py
index 5dd5b768..07e38ccb 100644
--- a/tests/test_connection.py
+++ b/tests/test_connection.py
@@ -3081,6 +3081,12 @@ def test_dataloss_protection(node_factory, bitcoind):
Path(dbpath).write_bytes(orig_db)
l2.start()
+ # l1 will keep trying to reconnect, but it's using exponential backoff,
+ # which only gets reset after the connection has lasted MAX_WAIT_SECONDS (300)
+ # which it hasn't. Speed things up (and avoid a timeout flake!) by reconnecting
+ # manually now.
+ l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
+
# l2 should freak out!
l2.daemon.wait_for_log("Peer permanent failure in CHANNELD_NORMAL:.*Awaiting unilateral close")
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.