pytest: clean up JSON sql test.
What the developer wrote
Authored by Rusty Russell
pytest: clean up JSON sql test.
1. Establish a channel with l3; we already have one with l2.
2. Don't bother generating 6 more blocks (fundchannel ensures it's mined).
3. Allow htlcs to be empty: Whitslack reported that happens for him
4. Use only_one() to access where we insist there is only one element in the list.
5. Tighten tests to assert the exact contents, not just test some.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/8497
What changed, and why it matters
This commit is a cleanup of an existing automated test for the SQL plugin. It changes which test nodes open channels, removes unnecessary block generation, and makes the test assertions more precise. There is no change to production code, no security fix, and no vulnerability being addressed.
No security action needed. This is a test-only refactor and can be treated as ordinary quality/maintenance work.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff modifies tests/test_plugin.py::test_sql only. It switches the channel funding target from l2 to l3, removes a redundant bitcoind.generate_block(6) call, wraps JSON row access with only_one(), and tightens assertions to compare exact expected dictionaries. The commit message notes that htlcs may be empty in some test environments. No Core Lightning runtime code is changed.
Changed components
tests/test_plugin.pyInspect captured patch +19 / −9
diff --git a/tests/test_plugin.py b/tests/test_plugin.py
index 788942c6..82f832d4 100644
--- a/tests/test_plugin.py
+++ b/tests/test_plugin.py
@@ -4045,19 +4045,29 @@ def test_sql(node_factory, bitcoind):
wait_for(lambda: l3.rpc.sql("SELECT * FROM nodes WHERE alias = '{}'".format(alias))['rows'] != [])
# Test json functions
- l1.fundchannel(l2)
- bitcoind.generate_block(6)
- l1.rpc.pay(l2.rpc.invoice(amount_msat=1000000, label='inv1000', description='description 1000 msat')['bolt11'])
- ret = l1.rpc.sql("SELECT json_object('peer_id', hex(pc.peer_id), 'alias', alias, 'htlcs',"
+ scidl1l3, _ = l1.fundchannel(l3)
+ l1.rpc.pay(l3.rpc.invoice(amount_msat=1000000, label='inv1000', description='description 1000 msat')['bolt11'])
+
+ # Two channels, l1->l3 *may* have an HTLC in flight.
+ ret = l1.rpc.sql("SELECT json_object('peer_id', hex(pc.peer_id), 'alias', alias, 'scid', short_channel_id, 'htlcs',"
" (SELECT json_group_array(json_object('id', hex(id), 'amount_msat', amount_msat))"
" FROM peerchannels_htlcs ph WHERE ph.row = pc.rowid)) FROM peerchannels pc JOIN nodes n"
" ON pc.peer_id = n.nodeid ORDER BY n.alias, pc.peer_id;")
assert len(ret['rows']) == 2
- row1 = json.loads(ret['rows'][0][0])
- row2 = json.loads(ret['rows'][1][0])
- assert row1['peer_id'] == format(l2.info['id'].upper())
- assert len(row2['htlcs']) == 1
- assert row2['htlcs'][0]['amount_msat'] == 1000000
+ row1 = json.loads(only_one(ret['rows'][0]))
+ row2 = json.loads(only_one(ret['rows'][1]))
+ assert row1 in ({"peer_id": format(l3.info['id'].upper()),
+ "alias": l3.rpc.getinfo()['alias'],
+ "scid": scidl1l3,
+ "htlcs": []},
+ {"peer_id": format(l3.info['id'].upper()),
+ "alias": l3.rpc.getinfo()['alias'],
+ "scid": scidl1l3,
+ "htlcs": [{"id": "30", "amount_msat": 1000000}]})
+ assert row2 == {"peer_id": format(l2.info['id'].upper()),
+ "alias": l2.rpc.getinfo()['alias'],
+ "scid": scid,
+ "htlcs": []}
def test_sql_deprecated(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.