The fact that we're storing a Vec<RemoteHandle<()>) internally is an
implementation detail.
Calling `spawn_with_handle` is done internally now, guarded by a `debug_assert!`
macro discouraging from doing it twice.
Prevent accidentally spawning a task that could outlive the actor system
and become a zombie.
Any long-lived task should be tied to its owner by keeping RemoteHandle around.
Handling the `Sync` message is quick because we internally use
concurrency to fetch attestations and announcement. This will not
actually block startup.
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.
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`.
Mariusz Klochowicz
Thomas Eizinger
Daniel Karzel
itchymax