Stumbled on this when writing actor tests.
We cannot create a failing test for this code at the moment, because our current test framework does not allow us to test at this granulairty level.
Nevertheless, we should fix this.
Rational:
If the maker is unable to contact the taker about the contract setup we fail now (previously we tried to continue).
This means, that we should only transition the maker's cfd to the new state if we are able to contact the maker.
Addresses #357 and #365. Although not a very large change, this PR ends up touching rather a lot of code.
* Converted types `Usd`, `Leverage` and `Percent` to something that is appropriate to this application
* Created new types `Price` and `InversePrice` to use for BTC/USD exchange rate with appropriate algebraic ops implemented as well.
* Added new positive tests
* The function `daemon::model::calculate_profit()` has been changed substantially as the updated types make the existing workflow needlessly complex
* Some tests (mostly in `cfd.rs` required updating) in order to make use of the new types.
* Minor edit to `.gitignore` to avoid accidental pushing of DB to repository--should have been it's own item, added here to fix a problem that arose during this work.
NOTE:
* There may be an excess of algebraic ops implemented, some pruning may be appropriate.
Fetching new events all over the place is cumbersome and it is likely that we will forget about doing so (e.g. atm we forgot doing this when receiving a roll-over request at the maker). Hence, we now fetch on a regular interval for a fixed timespan:
When starting up we fetch oracle events for the next 24h. Afterwards we check every 5 minutes again if there is a new event to check. This should ensure that we always know about needed events.
Include a generic Wallet actor constructor in the actor systems and allow
passing in a generic Wallet actor implementing xtra::Handlers into the cfd
actors.
Rename 'Maker' and 'Taker' to 'MakerActorSystem' and 'TakerActorSystem' for
readability.
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
This allows us to avoid the use of the constant in two places which
removes the dependency on the constant from the taker entirely.
The logic here is generally not great - in particular having the taker
anticipate, which announcement it is going to be - but this is the
least invasive way of making the term dynamic.
We have a 1:1 relationship (and the fact that we don't remove cfds) between cfd and order at the moment, so once the cfd was inserted we cannot creat another cfd for the same order.
Thus, we should remove the order from the feel by sending `None`.