Repository navigation
Ffi layer runtime issues #978
Description
Is there an existing issue for this?
- I have searched the existing issues
Which crate is this issue for?
payjoin-ffi / payjoin-test-utils
How did you obtain this crate?
Compiled from source
What version of the selected crate are you using?
payjoin 0.24.0 payjoin-test-utils 0.0.1
Current behavior
Originally found when trying to fix #974 I think we have a wider regression with our new testcontainers dep.
There seems to be a failure of runtime even though we have it blocked to not be async in its current form.
https://github.com/payjoin/rust-payjoin/actions/runs/17085193133/job/48447857125#step:10:1
Interestingly this does not actually cause the test to fail in the CI.
Expected behavior
Tests should pass
Steps to reproduce
Build and run the python ffi tests
Relevant log output
Database running on 127.0.0.1:32768
OHTTP relay binding to port [::]:40401
test_integration_v2_to_v2 (test.test_payjoin_integration_test.TestPayjoin) ... Executing <Task pending name='Task-1' coro=<IsolatedAsyncioTestCase._asyncioLoopRunner() running at /opt/hostedtoolcache/Python/3.9.23/x64/lib/python3.9/unittest/async_case.py:101> created at /opt/hostedtoolcache/Python/3.9.23/x64/lib/python3.9/unittest/async_case.py:117> took 3.635 seconds
thread '<unnamed>' (17266) panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/testcontainers-0.24.0/src/core/async_drop.rs:17:18:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Exception ignored in: <function TestServices.__del__ at 0x7fd1b47a4940>
Traceback (most recent call last):
File "/opt/hostedtoolcache/Python/3.9.23/x64/lib/python3.9/site-packages/payjoin/payjoin_ffi.py", line 10532, in __del__
_uniffi_rust_call(_UniffiLib.uniffi_payjoin_ffi_fn_free_testservices, pointer)
File "/opt/hostedtoolcache/Python/3.9.23/x64/lib/python3.9/site-packages/payjoin/payjoin_ffi.py", line 304, in _uniffi_rust_call
return _uniffi_rust_call_with_error(None, fn, *args)
File "/opt/hostedtoolcache/Python/3.9.23/x64/lib/python3.9/site-packages/payjoin/payjoin_ffi.py", line 315, in _uniffi_rust_call_with_error
_uniffi_check_call_status(error_ffi_converter, call_status)
File "/opt/hostedtoolcache/Python/3.9.23/x64/lib/python3.9/site-packages/payjoin/payjoin_ffi.py", line 335, in _uniffi_check_call_status
raise InternalError(msg)
payjoin.payjoin_ffi.InternalError: there is no reactor running, must be called from the context of a Tokio 1.x runtime
ok
test_receiver_persistence (test.test_payjoin_unit_test.TestReceiverPersistence) ... ok
test_sender_persistence (test.test_payjoin_unit_test.TestSenderPersistence) ... ok
test_missing_amount (test.test_payjoin_unit_test.TestURIs) ... ok
test_todo_url_encoded (test.test_payjoin_unit_test.TestURIs) ... ok
test_valid_uris (test.test_payjoin_unit_test.TestURIs) ... ok
test_valid_url (test.test_payjoin_unit_test.TestURIs) ... ok
----------------------------------------------------------------------
Ran 7 tests in 9.945s
OK
checked_payjoin_proposal_psbt: <payjoin.bitcoin.Psbt object at 0x7fd1b1d75520>
Operating system and version
Nixos 25.05
Activity
spacebear21 commentedon Aug 20, 2025
I think this issue has been around forever and is now more apparent with the testcontainers upgrade. Test cleanup doesn't shutdown the redis containers appropriately, which is why the test still passes despite the logged error. This is the same reason why Docker ends up with dozens of redis containers over time:
benalleng commentedon Aug 20, 2025
Was it just not logged in previous versions of our test-containers?
https://github.com/payjoin/rust-payjoin/actions/runs/17043170227/job/48311940797#step:11:1
from #962
spacebear21 commentedon Aug 20, 2025
I believe so, or maybe the old version wasn't even attempting to do cleanup.
DanGould commentedon Aug 20, 2025
I think @nothingmuch is still killing redis right now and we can just wish Docker good riddance to be done with the problem
nothingmuch commentedon Aug 26, 2025
can confirm, with @thebrandonlucas we've been working on uv and ran into this, rebasing on my yeet-redis branch sidestepped the issue so i think it originates from testcontainer's new async support
nothingmuch commentedon Aug 26, 2025
Note that there is a confounding issue in the python side of things, i tried to get this to trigger a CI failure but
python -m unittestappears to exit with status 0 despite this error: #996 (comment)spacebear21 commentedon Sep 19, 2025
Closed by #915