tests: fix flaky test_simple_close_dust_output_omitted mempool race
What the developer wrote
Authored by Ken Sedgwick
tests: fix flaky test_simple_close_dust_output_omitted mempool race
The test snapshots getrawmempool() and then calls getrawtransaction()
on each txid. In simple close both peers broadcast conflicting closer
txs: here l2's tx pays only 400sat fee (its entire 400sat balance goes
to fees since its own output is dust) while l1's pays 3375sat, so l1's
tx can RBF-replace l2's between the snapshot and the fetch. The
getrawtransaction() call on the replaced txid then fails with error -5
(No such mempool or blockchain transaction). A CI failure showed
exactly this ordering: l2 broadcast its closer tx, l1's higher-fee tx
replaced it 14ms later, and the test's per-txid fetch raced the
replacement.
Retry the whole snapshot-and-check loop when a txid vanishes
mid-iteration, keeping the single-output assertion hard. This is the
same class of mempool race fixed for test_simple_close_delay_broadcast
in 5ae0705f2 ("tests: fix flaky test_simple_close_delay_broadcast
mempool race").
Changelog-None
What changed, and why it matters
This commit fixes a flaky automated test, not a security bug in the actual Core Lightning software. The test sometimes failed because it took a snapshot of Bitcoin's memory pool and then tried to fetch each transaction, but one transaction could be replaced by a higher-fee version in the tiny gap between those two steps. The fix simply retries the snapshot-and-check loop if a transaction disappears mid-check. No user funds, network behavior, or real-world security is affected.
No security action needed. Treat as a normal test-stability improvement.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The change is confined to tests/test_closing.py. It wraps an existing mempool assertion loop in a helper that catches bitcoin.rpc.InvalidAddressOrKeyError (the Python-bitcoinlib wrapper for bitcoind’s -5 ‘No such mempool or blockchain transaction’) and retries via wait_for(). The assertion that every closing transaction has exactly one non-fee output remains unchanged. This is purely a test-hardening patch against an RBF mempool race between two peers’ conflicting close transactions.
Changed components
tests/test_closing.pyInspect captured patch +16 / −5
diff --git a/tests/test_closing.py b/tests/test_closing.py
index 09c1dc0e..97690f53 100644
--- a/tests/test_closing.py
+++ b/tests/test_closing.py
@@ -4301,11 +4301,22 @@ def test_simple_close_dust_output_omitted(node_factory, bitcoind):
# Every closing tx in the mempool must have exactly 1 output: the dust
# output is omitted in all variants. Elements appends an explicit fee
# output (scriptPubKey type 'fee') which must not be counted here.
- for txid in bitcoind.rpc.getrawmempool():
- tx = bitcoind.rpc.getrawtransaction(txid, True)
- real_vouts = [v for v in tx['vout'] if v['scriptPubKey'].get('type') != 'fee']
- assert len(real_vouts) == 1, \
- f"tx {txid} has {len(tx['vout'])} outputs; expected 1 (dust omitted)"
+ # Both sides broadcast conflicting closer txs, and l1's higher-fee tx
+ # can RBF-replace l2's between our getrawmempool() snapshot and the
+ # getrawtransaction() call (bitcoind error -5), so retry with a fresh
+ # snapshot until we see a consistent one.
+ def closing_txs_have_single_output():
+ try:
+ for txid in bitcoind.rpc.getrawmempool():
+ tx = bitcoind.rpc.getrawtransaction(txid, True)
+ real_vouts = [v for v in tx['vout'] if v['scriptPubKey'].get('type') != 'fee']
+ assert len(real_vouts) == 1, \
+ f"tx {txid} has {len(tx['vout'])} outputs; expected 1 (dust omitted)"
+ except bitcoin.rpc.InvalidAddressOrKeyError:
+ return False
+ return True
+
+ wait_for(closing_txs_have_single_output)
def test_simple_close_restart(node_factory, bitcoind):
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.