Ffi layer runtime issues

[benalleng]

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

[spacebear21]

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]

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]

I believe so, or maybe the old version wasn't even attempting to do cleanup.

[DanGould]

I think @nothingmuch is still killing redis right now and we can just wish Docker good riddance to be done with the problem

[nothingmuch]

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]

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 unittest appears to exit with status 0 despite this error: #996 (comment)

[spacebear21]

Closed by #915