Previously we tried to wait longer upon errors on startup, but that did not fix the problem:
```
May 28 05:35:01.440 INFO monero_harness: Starting wallet: bob
May 28 05:35:04.350 INFO testcontainers::core::wait_for_message: Found message after comparing 16 lines
May 28 05:35:04.409 WARN monero_harness: Monero wallet RPC emitted error error sending request for url (http://127.0.0.1:49183/json_rpc): operation was canceled: connection closed before message completed - retrying to create wallet in 2 seconds...
May 28 05:35:06.413 WARN monero_harness: Monero wallet RPC emitted error error sending request for url (http://127.0.0.1:49183/json_rpc): operation was canceled: connection closed before message completed - retrying to create wallet in 2 seconds...
May 28 05:35:08.416 WARN monero_harness: Monero wallet RPC emitted error error sending request for url (http://127.0.0.1:49183/json_rpc): operation was canceled: connection closed before message completed - retrying to create wallet in 2 seconds...
May 28 05:35:10.420 WARN monero_harness: Monero wallet RPC emitted error error sending request for url (http://127.0.0.1:49183/json_rpc): operation was canceled: connection closed before message completed - retrying to create wallet in 2 seconds...
May 28 05:35:12.424 WARN monero_harness: Monero wallet RPC emitted error error sending request for url (http://127.0.0.1:49183/json_rpc): operation was canceled: connection closed before message completed - retrying to create wallet in 2 seconds...
thread 'alice_manually_redeems_after_enc_sig_learned' panicked at 'called `Result::unwrap()` on an `Err` value: All retry attempts for creating a wallet exhausted
```
Thus we now drop the container upon error and try to spin up a new one. If the container is not up within 5 minutes we timeout.
Recently we se this problem on CI quite often:
```
May 27 01:26:55.898 INFO testcontainers::core::wait_for_message: Found message after comparing 80 lines
May 27 01:27:00.858 INFO testcontainers::core::wait_for_message: Found message after comparing 2 lines
May 27 01:27:00.859 INFO monero_harness: Starting monerod: DQma_monerod
May 27 01:27:08.143 INFO testcontainers::core::wait_for_message: Found message after comparing 183 lines
May 27 01:27:08.204 INFO monero_harness: Starting miner wallet: miner
May 27 01:27:09.832 INFO testcontainers::core::wait_for_message: Found message after comparing 16 lines
May 27 01:27:12.261 INFO monero_harness: Starting wallet: alice
May 27 01:27:14.482 INFO testcontainers::core::wait_for_message: Found message after comparing 16 lines
thread 'alice_punishes_after_restart_if_bob_dead' panicked at 'called `Result::unwrap()` on an `Err` value: error sending request for url (http://127.0.0.1:49177/json_rpc): operation was canceled: connection closed before message completed
```
Given the message `connection closed before message completed` it is likely that the `monero-wallet-rpc` is not fully started yet.
Unfortunately we cannot wait to see a different message in the logs, because there are just no further deterministic messages after the one we are currently listening on.
to overcome this problem without extending testcontainers we introduce a retry mechanism when creating the wallet.
Invoking cargo tomlfmt on all files is a PITA and as we can see from
the CI scripts, it is often forgotten to as new crates are added to
the workspace.
Using dprint for toml files fixes this.
Unfortunately, we can't use dprint for Rust code yet because there
hasn't been a release of rustfmt in quite a while but we are already
using features from a newer rustfmt via rustup.
The message `JOINING all threads` is unfortunately not deterministic, it can happen that it just is not printed in the logs.
For Monerod container the message is set to `RPC server started ok`. This message appears in both a test run that was hanging with `JOINING all threads` and a successful run. Initially the message was set to `core RPC server started ok` with `core` being a variable value. We assume that `core` does not change, but did not to further code analysis what values it can be.
For Monero Wallet RPC container the message is set to `Run server thread name: RPC` which is what it was set to initially. After several container runs this message seems to be reasonable - there are no recorded issues of the Wallet RPC container hanging, but we had problems with Monerod in the past.
1. Split up image::Monero into Monerod and MoneroWalletRpc
2. Don't use `bash` to run the internal command. Instead we disable
the entrypoint script as per https://github.com/XMRto/monero#raw-commands
3. Remove the start up delay by listening for the correct log message.
To make this more resilient, we make the log level NOT configurable and
instead always log verbosely.
- Swap-id is exchanged during execution setup. CLI (Bob) sends the swap-id to be used in his first message.
- Transfer poof and encryption signature messages include the swap-id so it can be properly associated with the correct swap.
- ASB: Encryption signatures are associated with swaps by swap-id, not peer-id.
- ASB: Transfer proofs are still associated to peer-ids (because they have to be sent to the respective peer), but the ASB can buffer multiple
- CLI: Incoming transfer proofs are checked for matching swap-id. If a transfer proof with a different swap-id than the current executing swap is received it will be ignored. We can change this to saving into the database.
Includes concurrent swap tests with the same Bob.
- One test that pauses and starts an additional swap after the transfer proof was received. Results in both swaps being redeemed after resuming the first swap.
- One test that pauses and starts an additional swap before the transfer proof is sent (just after BTC locked). Results in the second swap redeeming and the first swap being refunded (because the transfer proof on Bob's side is lost). Once we store transfer proofs that we receive during executing a different swap into the database both swaps should redeem.
Note that the monero harness was adapted to allow creating wallets with multiple outputs, which is needed for Alice.
This also formats `log` events more nicely. Instead of
```
Mar 29 09:46:16.775 INFO log: Found message after comparing 82 lines log.target="testcontainers::core::wait_for_message" log.module_path="testcontainers::core::wait_for_message" log.file="/home/thomas/.cargo/registry/src/github.com-1ecc6299db9ec823/testcontainers-0.12.0/src/core/wait_for_message.rs" log.line=35
```
We now have
```
Mar 29 09:57:15.860 INFO testcontainers::core::wait_for_message: Found message after comparing 81 lines
```
Prefixing docker-containers and -networks is a necessity to be able to spin up multiple containers and networks.
However, there is no reason to prefix the wallet names that live inside a container. One cannot add a wallet with
the same name twice, so the prefixing of wallets does not bring any advantage. When re-opening a wallet by name
the wallet name prefix is cumbersome and was thus removed.
The monero harness wallet always starts a miner that mines new blocks every second.
This can conflict with additionally triggering block generation and cause this error:
```
monero_rpc::rpc::monerod: generate blocks response: {
"error": {
"code": -7,
"message": "Block not accepted"
},
"id": "1",
"jsonrpc": "2.0"
}
```
Since the miner is generating blocks anyway we can wait for the wallet to catch up.
Refresh is done upon querying the balance, thus the refresh calls were removed.
This allows us to see the response from the monerod client on debug.
When the monero-harness was split up into harness and rpc this was overlooked.
We need the debug logs to investigate the monero harness CI fail bug.
CI keeps failing when generating blocks, but response is only printed on debug level.
To investigate what is the problem change monero-harness log levels to debug.
Upgrade bitcoin harness dependency to latest commit
Upgrade backoff to fix failing tests. The previous version of backoff had a broken version of the retry function. Upgraded to a newer comit which fixes this problem.
Upgrade hyper to 0.14 as the 0.13 was bringing in tokio 0.2.24
Upgraded bitcoin harness to version that uses tokio 1.0 and reqwest 0.11
Upgrade reqwest to 0.11. Reqwest 0.11 uses tokio 1.0
Upgrade libp2p to 0.34 in preparation for tokio 1.0 upgrade
Rust fmt automatically groups the imports (from top to bottom) as `pub use` `use crate` and `use`.
There is no need to introduce sections which cause annoyance when auto importing using the IDE.
Daniel Karzel
Thomas Eizinger
dependabot[bot]
Franck Royer
rishflab
Lucas Soriano del Pino
Philipp Hoenisch