398: Don't fail for loops r=da-kami a=da-kami
We should not fail for loops where we loop over cfds to process state updates based on information we learned / restart.
We use a macro to wrap all fallible code in the loop to just print an error and continue.
Note: I went over the codebase in search of other for loops, maybe someone else can do another grep :)
Co-authored-by: Daniel Karzel <daniel@comit.network>
402: Revise Git dependencies r=thomaseizinger a=thomaseizinger
- Change to secp256k1-zkp upstream
- Patch secp256k1-zkp via root Cargo.toml
- Depend on latest upstream HEAD instead of fork
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
390: Fix precision of Usd and Percent to 2 decimal upon serialization r=thomaseizinger a=thomaseizinger
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
401: Taker cleans up order feed r=da-kami a=da-kami
fixes https://github.com/comit-network/hermes/issues/399
The first commit was mostly added for ensuring sanity - this should also help us for scenarios where we restart the taker and the maker sends over the same current order as before. Instead of bailing in `insert` we could handle this in a less intrusive way, because in some scenarios (as the one above) it is actually expected at the moment, so we might not want to treat it as error. For now I kept it simple and just bail (otherwise the insert would fail...) - that should not cause side effects.
Co-authored-by: Daniel Karzel <daniel@comit.network>
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`.
395: Bail only if transaction does not make it on-chain r=luckysori a=luckysori
With bd15462af7 we no longer wrongly report an error when failing to broadcast a transaction because it's already on-chain. It's also a slight improvement imo.
Additionally, I tried to simplify this function with 3e8e6bc06e, which seems a lot better to me, but I could have missed something.
Co-authored-by: Lucas Soriano del Pino <l.soriano.del.pino@gmail.com>
392: Use fork for secp256k1-zkp r=bonomat a=bonomat
Because of bug in upstream library where the release build removes the actual computation of adaptor signatures
Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at>
384: Refer to correct ID when joining orders r=thomaseizinger a=thomaseizinger
Co-authored-by: Daniel Karzel <daniel@comit.network>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
380: Treat `InvalidOrderId` from maker as `Rejected` r=luckysori a=luckysori
If the maker tells the taker that the take request was for an invalid order ID, we should do something other than panic. For example,
logging and treating the situation as if the maker had rejected the take request.
Co-authored-by: Lucas Soriano del Pino <l.soriano.del.pino@gmail.com>
If the maker tells the taker that the take request was for an invalid
order ID, we should do something other than panic. For example,
logging and treating the situation as if the maker had rejected the
take request.
374: Validate sqlx insertions r=klochowicz a=klochowicz
Validate the insertions & add a new test to check cfd feed contents
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
372: Print git tag when starting maker/taker r=bonomat a=bonomat
Prints this on latest master:
```bash
2021-10-19 09:08:22 INFO Running version: preview-133-ga998367
```
Co-authored-by: Philipp Hoenisch <philipp@hoenisch.at>
367: Remove pending roll over proposal upon rejection r=da-kami a=da-kami
fixes#359
too me a bit to figure out how easy the fix is 😅
Co-authored-by: Daniel Karzel <daniel@comit.network>
356: Add timeout to contract-setup r=thomaseizinger a=thomaseizinger
- Remove stale TODO
- Add log statements to sections of contract-setup
- Add timeouts to awaiting messages during contract setup
- Fix typo
- Add timeouts to rollover messages
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
347: Maker actor system r=luckysori a=luckysori
How does this attempt at an actor system look?
- The constructor just hooks everything up in the same way that `main` currently does. I think we want this to be consistent between tests and production.
- The closures allow us to build whatever actors we want so long as they respect the contract expressed in the trait bounds. Maybe this is clunky. This could be leveraged to, for example, construct a `monitor::Actor` stand-in which immediately finds any transactions we subscribe to.
- I assume both the `wallet` and `db` arguments can be previously initialised for the purpose of testing, like we've done in the past.
363: Add log statement for completed roll over r=da-kami a=thomaseizinger
Co-authored-by: Lucas Soriano del Pino <l.soriano.del.pino@gmail.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
bors[bot]
Thomas Eizinger
Daniel Karzel
Lucas Soriano del Pino
Mariusz Klochowicz
Philipp Hoenisch
dependabot[bot]