f51ce7be85
`mine_txid_or_rbf` uses is_in_log, which grabs the first line. Thus it doesn't track when a txid gets "RBF"ed by itself, such as:
```
DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: RBF onchain txid 5df8474399e43c58cc45efb6acf1ae08fe678bea9a27d131628394a009cda361 (fee 122sat) with txid 5df8474399e43c58cc45efb6acf1ae08fe678bea9a27d131628394a009cda361 (fee 122sat)
...
INFO 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: RBF onchain txid 5df8474399e43c58cc45efb6acf1ae08fe678bea9a27d131628394a009cda361 (fee 122sat) with txid 044a564a2b6f8c7c212246e4973a303d24ce0dcd31c470a9ea272f314cf6a4ce (fee 3630sat)
...
DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: RBF onchain txid 044a564a2b6f8c7c212246e4973a303d24ce0dcd31c470a9ea272f314cf6a4ce (fee 3630sat) with txid 044a564a2b6f8c7c212246e4973a303d24ce0dcd31c470a9ea272f314cf6a4ce (fee 3630sat)
...
DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: RBF onchain txid 044a564a2b6f8c7c212246e4973a303d24ce0dcd31c470a9ea272f314cf6a4ce (fee 3630sat) with txid 044a564a2b6f8c7c212246e4973a303d24ce0dcd31c470a9ea272f314cf6a4ce (fee 3630sat)
```
The simplest fix is to only use INFO lines, which are printed when we actually increase fee.
```
def test_onchaind_replay(node_factory, bitcoind):
...
# l1 should still notice that the funding was spent and that we should react to it
_, txid, blocks = l1.wait_for_onchaind_tx('OUR_DELAYED_RETURN_TO_WALLET',
'OUR_UNILATERAL/DELAYED_OUTPUT_TO_US')
assert blocks == 200
bitcoind.generate_block(200)
# Could be RBF!
> l1.mine_txid_or_rbf(txid)
tests/test_closing.py:1860:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
contrib/pyln-testing/pyln/testing/utils.py:1292: in mine_txid_or_rbf
wait_for(lambda: rbf_or_txid_broadcast(txids))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
success = <function LightningNode.mine_txid_or_rbf.<locals>.<lambda> at 0x7f5d55f770d0>
timeout = 180
def wait_for(success, timeout=TIMEOUT):
start_time = time.time()
interval = 0.25
while not success():
time_left = start_time + timeout - time.time()
if time_left <= 0:
> raise ValueError("Timeout while waiting for {}".format(success))
E ValueError: Timeout while waiting for <function LightningNode.mine_txid_or_rbf.<locals>.<lambda> at 0x7f5d55f770d0>
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
||
|---|---|---|
| .. | ||
| pyln/testing | ||
| tests | ||
| .gitignore | ||
| Makefile | ||
| README.md | ||
| pyproject.toml | ||
README.md
pyln-testing: A library to write tests against Core Lightning
This library implements a number of utilities that help building tests for Core Lightning nodes. In particular it provides a number of pytest fixtures that allow the management of a test network of a given topology and then execute a test scenarion.
pyln-testing is used by Core Lightning for its internal tests, and by the
community plugin directory to exercise the plugins.
Installation
pyln-testing is available on pip:
pip install pyln-testing
Alternatively you can also install the development version to get access to currently unreleased features by checking out the Core Lightning source code and installing into your python3 environment:
git clone https://github.com/ElementsProject/lightning.git
cd lightning/contrib/pyln-testing
poetry install
This will add links to the library into your environment so changing the checked out source code will also result in the environment picking up these changes. Notice however that unreleased versions may change API without warning, so test thoroughly with the released version.
Testing GRPC Bindings
The grpc bindings can be tested by setting the CLN_TEST_GRPC=1
environment variable. This will cause the testing framework to use a
grpc client to talk to the cln-grpc plugin, rather than talking
directly to the node's JSON-RPC interface. Since the GRPC related
dependencies are guarded behind a feature flag in pyln-testing
you'll need to install it with the grpc feature enabled in order to
be able to run in this mode.
Below is a diagram of how the normal JSON-RPC interaction looks like, followed by one that display the grpc interaction:
CLN -- JSON-RPC -- LightningRpc -- pytest
\_____CLN_____/ \_______pytest_______/
CLN -- JSON-RPC -- cln-rpc -- rpc2grpc converters -- grpc interface -- python grpc client -- python grpc2json converter -- pytest
\_____CLN_____/ \___________cln-grpc-plugin____________________/ \__________________________pytest________________________/
As you can see the grpc mode attempts to emulate the simple JSON-RPC
mode by passing the call through a number of conversions. The last
step grpc2json is rather incomplete, and will cause quite a few
tests to fail for now, until the conversion is completed and we reach
feature parity between the interaction modes.