We are aware of issues of timeouts when waiting for acknowledgements.
Also, to properly supports acks in a multiple swap context, we need to
revert to doing event processing on the behaviour so that we can link
leverage the `RequestResponse` libp2p behaviour and link the messages
requests ids to swap ids when receiving an ack or response.
Acks are usefully for specific scenarios where we queue a message on the
behaviour to be sent, save as sent in the DB but crash before the
message is actually sent. With acks we are able to resume the swap,
without ack, the swap will abort (refund).
`alice::swap::run_until` will be called once the execution setup is
done. The steps before are directly handled by the event loop,
hence no channels are needed for said steps: connection established,
swap request/response & execution setup.
The `EventLoop` will use the `Builder` interface to instantiate a
`Swap` upon receiving a `SwapRequest` and successfully doing an
execution setup.
Before this change, the `EventLoop` would have to hold the path to the
db and re-open the db everytime it wants to construct a swap.
With this change, we can open the DB once and then hold a
`Arc<Database>` in the `EventLoop` and pass it to new `Swap`s structs.
179: Watch only tmp monero wallet r=da-kami a=da-kami
When initializing Monero wallet, try to open temporary wallet, if opening errors then try to create it. If creating errors then fail with message asking the user to configure the wallet RPC.
If opening / creation succeeds get the block_height to verify that connection to wallet works, then proceed to swap.
Note: RPC error handling is hacky, but I don't see the value of investing time into that at this point. The problem is, that we don't deal with the json rpc errors properly for calls were we don't serialize the result into an object (because the response is empty). Eventually we should switch to using https://github.com/thomaseizinger/rust-jsonrpc-client but that does not support parameters `by-name` yet, see: https://github.com/thomaseizinger/rust-jsonrpc-client/issues/20
Co-authored-by: Daniel Karzel <daniel@comit.network>
170: Cancel and refund commands r=da-kami a=da-kami
I plugged the cancel and refund logic into the current state/state-machine logic of the swap.
## Follow ups (out of scope)
We might want to record issues to be tackled later, since we are on a tight time budget :)
Please let me know what you think @D4nte @rishflab
### Problems with `ack` after sending a message
Alice was waiting forever when awaiting the `ack` from bob when sending the lock proof in case she runs into a dial error. It seems the `acks` can cause the program to hang. This is a severe problem that we most probably will encountered in production at some point. For this PR I wrapped the `ack` of Alice upon sending the `encsig` in a timeout to work around this problem, see 7463081f88 - but **we might want to consider to remove all `ack` message. I don't see much value in them if we don't have a resilient retry strategy.**
### Do not require Monero wallet for cancel/refund
The cancel/refund commands don't require a monero wallet.
In this PR we re-uses the builder which requires the monero wallet as well - and we check for the monero balance upon wallet initialization, so the command will fail if no monero wallet is started.
### Save Alice connection info in Bob DB
Save Alice's peer-id/address in DB: It's cumbersome for the user to lookup those details again.
Co-authored-by: Daniel Karzel <daniel@comit.network>
This was introduced due to a CI run, where Bob included tx_refund, but Alice had waited until T2 had expired,
and then went for punishing Bob instead of refunding.
Weirdly, Alice's punich transaction did not fail in that scenario.
If dialing Bob fails Alice waits for the acknowledgement of the transfer proof indefinitely.
The timout prevents her execution from hanging.
Added a ToDo to re-visit the ack receivers. They don't add value at the moment and should be removed.
