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.
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.
Mariusz Klochowicz
Thomas Eizinger
Daniel Karzel