Handling the `Sync` message is quick because we internally use
concurrency to fetch attestations and announcement. This will not
actually block startup.
Running this test with `--nocapture` reveals that we have unmocked
handlers. Adding these mocks fixes those panics (which are being
captured by tokio and hence did not abort the test).
Additionally we specialize the `mock_common_handlers` function to just
deal with the two `Sync` messages to make it clear that no more mocks
should be added to this function.
This is a backwards-incompatible change in regards to the database
because we previously serialized UUIDs and now expect to deserialize
public keys.
It is a first step towards #576.
Connection actor takes care of establishing a connection to the maker and is
monitoring its status.
The connection actor:
- listens for periodically sent heartbeat messages from the maker,
- publish the maker status on a watch::channel feed outside TakerActorSystem,
- observe changes on the watch channel and shut down Rocket if maker goes offline
Note: this is a stepping stone resulting in temporary behaviour. Eventually,
we'd want to support reconnecting to the maker as well as operating the
taker without the maker being online (with a limited set of actions).
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Add configurable log levels on taker and maker and start tracing connection related information to track down a problem where the taker does not receive orders but there are not connection errors on both sides.
In case we already have a cfd for the received order we bail, because that should not happen.
If we already know the order, but don't have a related cfd we don't insert but still send it out on the order feed.
We should remove the order as soon as we know that we will create a cfd out of it.
The (automated) maker reacts on the state change on the feed and may trigger creating a new order.
If we only remove the order at the end the `None` might arrive at the taker after we send the new order.
Furthermore, we should always remove the order independent of accept/reject, so this is done only once upon handling the take request now.
Note that due to this async nature of the application it can still happen that the taker receives `None` after the new `Some(order)`, but this behaviour becomes less likely and the code is generally more correct.
We could also make sending the message to the taker sync, but that might have unwanted, long-blocking side effects.
`do_send` did not inspect any errors, while Cfd actors support returning errors
if an action performed on them failed.
This matches the code used in production in HTTP requests.
Slight changes in the test were required as the test failed
otherwise (particularly, on unhandled monitoring of oracle attestation).
Cfd protocol got moved into a separate repository.
All references of `cfd_protocol` were renamed to `maia`.
Patch cargo.toml with a fixed git revision until it gets a public release.
Thomas Eizinger
Mariusz Klochowicz
Daniel Karzel
itchymax
itchymax