By default tests use the same heartbeat interval as production code.
Allow adjusting the value using builder pattern is tests that otherwise take too
long to complete (as they wait for timeout to trigger).
Disable long-running test to speed up build/test cycle for devs.
This means it is not run by default, in order to run it you have to specify the
test name or run `cargo test -- --ignored`
The dirty shutdown we observed were caused by the sqlite pool patiently waiting
until we close the connection we've opened in the application setup.
This is turn was eventually triggering Rocket timeout (which is by default
configured to wait 5s for cleanup).
Tighten the scope of connections needed during application startup only to the
necessary minimum (housekeeping & loading cfds at startup)
Originally we thought we need this enum because we would need to use
`MessageChannel`s from the rocket layer. But we can actually fully
qualify the address without issues.
We also introduce `xtra_productivity` to remove some of the indirection
that is happening in this file.
Note: Projection actor is used across both taker and maker, so it really should
publish information about connected counterparty.
Taker should use that channel for deriving maker online status.
Oracle event-id and Dlc have to exist together, one without the other is incomplete, hence we move the event id inside.
Note that the ID is actually already know to the Dlc as part of the `cet` hashmap, but this was not cleaned up in this patch.
This patch goes towards getting the model boundaries right to transition the architecture towards an event model.
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.