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.
Only the attestation relevant for the cfds, based on the event id, should trigger monitoring for the CET.
We now properly filter the monitoring parameters by event id upon attestation.
Without the filter we ran into the error `No CET for oracle event found`, which is expected when trying to find CETs for an event that does not match.
Since an error in the loop can also have unwanted side effects we wrap it with a `try_continue`.
Thomas Eizinger
Mariusz Klochowicz
Daniel Karzel
itchymax
itchymax