Instead of blocking and awaiting for connection to maker before the start, spawn
the connection attempt in a separate task that will also attempt to reconnect if
the maker goes offline.
Extend the unit test to cover the new behaviour.
Do not shutdown the taker upon connection loss anymore.
Co-authored-by: rishflab <rishflab@hotmail.com>
It only makes sense to allow proposing a settlement when in `Open` state.
Theoretically we could argue that it should be allowed in `PendingRefund` and `PendingCommit`, but I don't see an advantage in that.
Note: This only guards the taker side, no guards were added to the maker side because it remains unclear if the deamon should contain logic for this, or we always want to handle acceptance criteria for settlement from the outside.
A configurable settlement interval for the maker causes friction when implementing auto-rollover, because the settlement interval is not known to the taker.
The settlement interval should not be configurable, thus the configurable settlement interval is removed on the maker side.
The cfd actors and oracle actor use a global constant to decide the settlement interval and oracle even lookahead.
Not pulling the constant into the actors is a conscious decision, it allows us to set this to a different value in the actor tests.
The fact that we use the same constant for cfd actor and oracle actor is an implementation detail.
The projection actor is responsible in preparing data for the HTTP API and consequently for the UI.
While this is commit provides only the foundation, in the long run we can:
- Reduce the logic happening in the rocket layer. `ToSseEvent` can likely go away.
- Reduce the complexity for other actors in what needs to be updated when. All they should care about is sending updates to the projection actor. (mostly done)
- Improve test coverage. With a dedicated actor that does the projection, we should be able to write assertions in our integration tests that are closer to the UI.
`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.
Mariusz Klochowicz
Thomas Eizinger
bonomat
Daniel Karzel
scratchy