`do_send` on `MessageChannel` suffers from the same problems as
`Address#do_send` and `Address#do_send_async`.
Our uses only send messages that never fail so we don't need to adjust
anything.
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.
Thomas Eizinger
Mariusz Klochowicz
Daniel Karzel