pytest: fix flake in test_channel_lease_unilat_closes
What the developer wrote
Authored by Rusty Russell
pytest: fix flake in test_channel_lease_unilat_closes
```
2026-01-30T05:55:13.6654636Z # Note that l3 has the whole lease delay (minus blocks already mined)
2026-01-30T05:55:13.6655396Z _, _, l3blocks = l3.wait_for_onchaind_tx('OUR_DELAYED_RETURN_TO_WALLET',
2026-01-30T05:55:13.6656086Z 'OUR_UNILATERAL/DELAYED_OUTPUT_TO_US')
2026-01-30T05:55:13.6656618Z > assert l3blocks == 4032 - 6 - 2 - 1
2026-01-30T05:55:13.6657033Z E assert 4025 == (((4032 - 6) - 2) - 1)
```
Turns out that 43420433829 (tests: de-flake test that was failing on
cltv expiry) added a line to mine two more blocks, but the hardcoded
110 was not changed to 112, so we weren't actually waiting correctly.
Remove hardcoded numbers in favor of calculation, and do the same in
test_channel_lease_post_expiry (which was correct, for now).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This commit fixes a flaky test in Core Lightning's test suite. The test was using a hardcoded block number that became outdated after a previous change added more mined blocks. The fix replaces the hardcoded number with a dynamic calculation based on the actual blockchain height. This is purely a test reliability improvement and does not change any production code or affect real users.
No security action required. This is a test-only change improving test reliability. Reviewers may optionally verify the new height calculation matches the intended test state.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch modifies tests/test_closing.py in two test functions (test_channel_lease_post_expiry and test_channel_lease_unilat_closes). It replaces hardcoded expected block heights in log-wait assertions with values derived from bitcoind.rpc.getblockchaininfo()[‘blocks’]. In test_channel_lease_unilat_closes, the hardcoded value 110 was stale because a prior commit (43420433829) added two extra generate_block(1) calls without updating it, causing intermittent assertion failures on the remaining CSV delay blocks. The change makes the tests robust to prior block generation counts.
Changed components
tests/test_closing.pyInspect captured patch +4 / −2
diff --git a/tests/test_closing.py b/tests/test_closing.py
index e64295dc..0cc1c2b6 100644
--- a/tests/test_closing.py
+++ b/tests/test_closing.py
@@ -871,7 +871,8 @@ def test_channel_lease_post_expiry(node_factory, bitcoind, chainparams):
bitcoind.generate_block(6)
sync_blockheight(bitcoind, [l1, l2])
# make sure we're at the right place for the csv lock
- l2.daemon.wait_for_log('Blockheight: SENT_ADD_ACK_COMMIT->RCVD_ADD_ACK_REVOCATION LOCAL now 115')
+ height = bitcoind.rpc.getblockchaininfo()['blocks']
+ l2.daemon.wait_for_log(f'Blockheight: SENT_ADD_ACK_COMMIT->RCVD_ADD_ACK_REVOCATION LOCAL now {height}')
# We need to give l1-l2 time to update their blockheights
for i in range(0, 4000, 1000):
@@ -980,7 +981,8 @@ def test_channel_lease_unilat_closes(node_factory, bitcoind):
bitcoind.generate_block(2)
sync_blockheight(bitcoind, [l1, l2, l3])
# make sure we're at the right place for the csv lock
- l2.daemon.wait_for_log('Blockheight: SENT_ADD_ACK_COMMIT->RCVD_ADD_ACK_REVOCATION LOCAL now 110')
+ height = bitcoind.rpc.getblockchaininfo()['blocks']
+ l2.daemon.wait_for_log(f'Blockheight: SENT_ADD_ACK_COMMIT->RCVD_ADD_ACK_REVOCATION LOCAL now {height}')
l2.stop()
# unilateral close channels l1<->l2 & l3<->l2
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.