322: Cleanup in Cfd actors r=klochowicz a=klochowicz
I started out trying to fix a common gotcha (forgetting to refresh Cfd feed),
and then realised that I was not far off of addressing a bunch of TODOs in the code
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
332: Provide margin of counterparty r=bonomat a=bonomat
Very useful for the maker.
Not shown in the UI for now.
Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at>
329: Set default log level for whole crate r=da-kami a=bonomat
Resolves#325
We were setting a filter for the binaries only and the rest was on INFO.
```
2021-10-15 08:47:06 WARN (post_cfd_action) POST /api/cfd/<id>/<action>
2021-10-15 08:47:06 WARN 🥅 Catchers:
2021-10-15 08:47:06 WARN (unauthorized) 401
2021-10-15 08:47:06 WARN (unauthorized) /api 401
2021-10-15 08:47:06 WARN 📡 Fairings:
2021-10-15 08:47:06 WARN Shield (liftoff, response, singleton)
2021-10-15 08:47:06 WARN SQL migrations (ignite)
2021-10-15 08:47:06 WARN 'maker' Database Pool (ignite)
2021-10-15 08:47:06 WARN Create actors (ignite)
2021-10-15 08:47:06 INFO 🛡️ Shield:
2021-10-15 08:47:06 WARN 🚀 Rocket has launched from http://127.0.0.1:8001
2021-10-15 08:47:06 INFO New taker 0f54e159-75ac-4d65-9d9f-e37847e88572 connected on 127.0.0.1:64286
2021-10-15 08:47:13 INFO POST /api/order/sell application/json:
2021-10-15 08:47:13 DEBUG Received new order
2021-10-15 08:47:14 INFO GET /api/feed text/event-stream:
2021-10-15 08:47:16 INFO POST /api/order/sell application/json:
2021-10-15 08:47:16 DEBUG Received new order
2021-10-15 08:47:21 DEBUG Taker wants to take an order taker_id=0f54e159-75ac-4d65-9d9f-e37847e88572 quantity=0 order_id=ed6dfa48-275e-4eae-b2f5-5c3ad154eda4
2021-10-15 08:48:06 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-10-15T22:00:00.price?n=20
2021-10-15 08:48:34 INFO POST /api/order/sell application/json:
2021-10-15 08:48:34 DEBUG Received new order
2021-10-15 08:48:41 DEBUG Taker wants to take an order taker_id=0f54e159-75ac-4d65-9d9f-e37847e88572 quantity=11 order_id=7bbd174b-10a2-4776-9d00-afa41a8077ae
2021-10-15 08:48:45 INFO POST /api/cfd/7bbd174b-10a2-4776-9d00-afa41a8077ae/acceptOrder:
2021-10-15 08:48:45 DEBUG Maker accepts an order order_id=7bbd174b-10a2-4776-9d00-afa41a8077ae
2021-10-15 08:49:06 DEBUG Fetching announcement for /x/BitMEX/BXBT/2021-10-15T22:00:00.price?n=20
2021-10-15 08:49:38 INFO Lock transaction published with txid 09fdafb1125295ea66401e1160542fa39d5695d61d64255bb94431275f892cb4
2021-10-15 08:49:45 DEBUG Found relevant Bitcoin transaction txid=09fdafb1125295ea66401e1160542fa39d5695d61d64255bb94431275f892cb4 status=in mempool
```
Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at>
321: Use `MessageChannels` in `maker_inc_connections::Actor` r=luckysori a=luckysori
We would have liked to attach the stream of `TakerStreamMessage`s directly to the `MessageChannel`, but we failed and instead decided to let the `maker_inc_connections::Actor` send these messages to itself and then forward them to the `maker_cfd::Actor`.
---
I wasted a lot of time trying to send the message directly to the `maker_cfd::Actor`. I trust that `@thomaseizinger` can find a way, but I had to give up 😞
Co-authored-by: Lucas Soriano del Pino <l.soriano.del.pino@gmail.com>
We would have liked to attach the stream of `TakerStreamMessage`s
directly to the `MessageChannel`, but we failed and instead decided to
let the `maker_inc_connections::Actor` send these messages to itself
and then forward them to the `maker_cfd::Actor`.
Inserting cfd or updating its state requires a follow-up update on the Cfd feed
sent to the UI. Encapsulate the behaviour in functions that are shared
across Cfd actors.
307: Setting boundaries r=bonomat a=bonomat
This improves the UX slightly as the user knows what is the min and max amount.
The UI will default to min amount.
Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at>
318: Introduce a `fan_out::Actor` instead of iterating in the `oracle::Actor` r=thomaseizinger a=thomaseizinger
A fan-out actor takes an incoming message and forwards it to a set
of actors. This allows our `oracle::Actor` to be unaware, how many
other actors are interested in the attestation, thus simplifying it.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
315: Lock in profit on collaborative close price r=da-kami a=da-kami
fixes#312
Once we have collaborative close present in the state(s) we lock in the profit based on the price of the collaborative close.
Note: Currently no automated validation on the maker side if the given amounts and price of collaborative settlement are sane.
Co-authored-by: Daniel Karzel <daniel@comit.network>
Once we have collaborative close present in the state(s) we lock in the profit based on the price of the collaborative close.
Note: Currently no automated validation on the maker side if the given amounts and price of collaborative settlement are sane.
316: Provide more feedback to the user during collaborative settlement r=klochowicz a=klochowicz
Fixes#309
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
Simplify model's state machine as PendingClose only matters for the UI
(for user feedback & available actions).
Disallow proposing another settlement if one was already signed.
295: Db refactor r=thomaseizinger a=DeliciousHair
DB code refactoring for #88
The primary goal was to remove all of the calls to `serde_json::to_string()` for the data-handling, thus enabling us to do (more or less):
```rust
Order {
row.column,
...
}
```
as well as clean up the SQL for easier reading. This has mostly been accomplished, with further refinements easily accomplished once the upstream issues in `sqlx` are addressed. See #314 for issues we are tracking.
Co-authored-by: DelicioiusHair <mshepit@gmail.com>
The primary goal was to remove all of the calls to `serde_json::to_string()`
for the data-handling, thus enabling us to do (more or less):
```rust
Order {
row.column,
...
}
```
as well as clean up the SQL for easier reading. This has mostly been
accomplished, with further refinements easily accomplished once the
upstream issues in `sqlx` are addressed. See #314 for issues we are
tracking.
A fan-out actor takes an incoming message and forwards it to a set
of actors. This allows our `oracle::Actor` to be unaware, how many
other actors are interested in the attestation, thus simplifying it.
Anything that can fail (e.g. fetching oracle stuff) has to be tried before we change any state or notify the taker, otherwise it can happen that we remain in a failed state that causes very weird side effects.
313: Replace `Address` with `MessageChannel` in some key places r=luckysori a=luckysori
We may need to use `MessageChannel` instead of `Address` elsewhere (perhaps everywhere), but these definitely need to change.
---
Work towards #231.
Co-authored-by: Lucas Soriano del Pino <l.soriano.del.pino@gmail.com>
The `oracle::Actor` only needs to be able to send the
`oracle::Attestation` to an actor who can handle it. We were already
able to express this using trait bounds, but it was blocking us from
being able to make the `{maker_taker}_cfd::Actor` generic over
different actors due to infinite, cyclic types.
The `monitor::Actor` only needs to be able to send the
`monitor::Event` to an actor who can handle it. We were already able
to express this using trait bounds, but it was blocking us from being
able to make the `{maker_taker}_cfd::Actor` generic over different
actors due to infinite, cyclic types.
306: Borrow CfdState when updating state in the database r=klochowicz a=klochowicz
The function signature didn't need to take the whole state, as it was only
borrowed internally.
Removes the need for many `.clone()` calls sprinkled in the codebase.
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
302: Collaborative close payout r=da-kami a=da-kami
Distinguish between collaborative close and cet closing.
Moved the payout on the `Cfd` which decides what the payout of the `Cfd` is, where
- `None` means the payout is not decided yet (we can optimize that and potentially combine this with `profit` in another iteration)
- `Some(payout)` can be a refund, collaborative or cet payout
Refund is handled in an early exit guard based on the state.
Collaborative settlement has priority over cet payout (attestation). In case there is a collaborative settlement present we always return payout based on that.
Note: I am not totally sure if collaborative close payout should always have priority over attestation payout. We could do a more complex reasoning about the state as well, but I felt for now this is probably good enough and we can adapt based on experience. Happy for other suggestions :)
Co-authored-by: Daniel Karzel <daniel@comit.network>
Distinguish between collaborative close and cet closing.
Moved the payout on the `Cfd` which decides what the payout of the `Cfd` is, where
- `None` means the payout is not decided yet (we can optimize that and potentially combine this with `profit` in another iteration)
- `Some(payout)` can be a refund, collaborative or cet payout
Refund is handled in an early exit guard based on the state.
Collaborative settlement has priority over cet payout (attestation). In case there is a collaborative settlement present we always return payout based on that.
The function signature didn't need to take the whole state, as it was only
borrowed internally.
Removes the need for many `.clone()` calls sprinkled in the codebase.
304: Re-introduce library r=luckysori a=luckysori
If we want to write proper integration tests, we need to have a library crate.
---
Work towards #231.
Co-authored-by: Lucas Soriano del Pino <l.soriano.del.pino@gmail.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Lucas Soriano del Pino
bors[bot]
Thomas Eizinger
Mariusz Klochowicz
Philipp Hoenisch
dependabot[bot]
Daniel Karzel
DelicioiusHair