e2e tests are flaky

[shinghim]

when running ./contrib/test_local.sh, I'll occasionally get some e2e test failures:

 Running `/Users/shingng/git/rust-payjoin/target/debug/deps/e2e-6229002acaf8f9b4`

running 2 tests
Error: Database operation failed: IO error: could not acquire lock on "/var/folders/fd/0r_2nyj90fjdgy1pjj2pfbv80000gn/T/receiver_db/db": Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }
Error: Failed to create URI from BIP21: invalid BIP21 URI
test e2e::send_receive_payjoin_v1 ... FAILED
Using OHTTP Keys from config
Receive session established
Request Payjoin by sharing this Payjoin Uri:
bitcoin:bcrt1qfdyfe2kzrvwy0pp4qydayzqlyvytx64v7lku8f?amount=0.00054321&pj=HTTPS://LOCALHOST:54996/2FT0VFQNKQKKX%23RK1Q0DHUDLSPPZAYQQWKWPPU9D426FZXYVLV5XMZ7GNXLR4M69NKUM4Z+OH1QYP4RGJ08AQH98X9GUVG7QH54DU9ZQ3QKY5LTVMZPP46KXDCPND7LXQ+EX12HGPY6Q
Posting Original PSBT Payload request...
Sent fallback transaction
No response yet.
resume
No sessions to resume.
test e2e::send_receive_payjoin_v2 ... FAILED

failures:

---- e2e::send_receive_payjoin_v1 stdout ----

thread 'tokio-runtime-worker' panicked at payjoin-cli/tests/e2e.rs:138:18:
rx channel closed prematurely
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: JoinError::Panic(Id(11), ...)

---- e2e::send_receive_payjoin_v2 stdout ----
Database running on 127.0.0.1:55011
Directory server binding to port [::]:54996
OHTTP relay binding to port [::]:54997

thread 'e2e::send_receive_payjoin_v2' panicked at payjoin-cli/tests/e2e.rs:322:13:
Did not respond with Payjoin PSBT


failures:
    e2e::send_receive_payjoin_v1
    e2e::send_receive_payjoin_v2

test result: FAILED. 0 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 9.35s

error: test failed, to rerun pass `-p payjoin-cli --test e2e`

it's a bit flaky though - reruns usually will result in passing tests. I haven't taken a deep look into this yet, but just opening an issue to track

[benalleng]

Error: Database operation failed: IO error: could not acquire lock on "/var/folders/fd/0r_2nyj90fjdgy1pjj2pfbv80000gn/T/receiver_db/db": Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }
This seems to indicate some port is already reserved, perhaps some test failed once and did not cleanup properly..?

[spacebear21]

This was previously reported and closed here: #537 cc @DanGould

[DanGould]

I wonder if this is caused by a mere ctrl+C interrupt, and if so, if it is possible to make it so that such interrupts don't disrupt later runs.

We need to figure out how to reproduce the failures

[arminsabouri]

I wonder if this is caused by a mere ctrl+C interrupt, and if so, if it is possible to make it so that such interrupts don't disrupt later runs.

We need to figure out how to reproduce the failures

On top of signal handlers we would also want panic handlers. IIRC a test run that panics or receives a unhandled signal does not clean up the temp dir.

[spacebear21]

I believe #868 solves this particular source of flakiness (could not acquire lock on "/var/folders/fd/0r_2nyj90fjdgy1pjj2pfbv80000gn/T/receiver_db/db": Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" } due to concurrent access to the same receiver_db). If other flakiness issues come up we can re-open this or make new issues as needed.