We should remove the order as soon as we know that we will create a cfd out of it.
The (automated) maker reacts on the state change on the feed and may trigger creating a new order.
If we only remove the order at the end the `None` might arrive at the taker after we send the new order.
Furthermore, we should always remove the order independent of accept/reject, so this is done only once upon handling the take request now.
Note that due to this async nature of the application it can still happen that the taker receives `None` after the new `Some(order)`, but this behaviour becomes less likely and the code is generally more correct.
We could also make sending the message to the taker sync, but that might have unwanted, long-blocking side effects.
523: Use `send` instead of `do_send` in actor tests r=klochowicz a=klochowicz
`do_send` did not inspect any errors, while Cfd actors support returning errors
if an action performed on them failed.
This matches the code used in production in HTTP requests.
Slight changes in the test were required as the test failed
otherwise (particularly, on unhandled monitoring of oracle attestation).
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
`do_send` did not inspect any errors, while Cfd actors support returning errors
if an action performed on them failed.
This matches the code used in production in HTTP requests.
Slight changes in the test were required as the test failed
otherwise (particularly, on unhandled monitoring of oracle attestation).
511: Test cleanup r=klochowicz a=klochowicz
A small refactor, hopefully reducing entry barrier in creating new tests.
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
495: Release version 0.1.1 r=itchymax a=itchymax
Hi `@itchymax!`
This PR was created in response to a manual trigger of the release workflow here: https://github.com/itchysats/itchysats/actions/runs/1438605510.
I've bumped the versions in the manifest files in this commit: c3fc1ca871.
Merging this PR will create a GitHub release and publish the library to crates.io!
Co-authored-by: itchymax <itchymax@protonmail.com>
490: Depend on cfd protocol from `maia` repository r=klochowicz a=klochowicz
Cfd protocol got moved into a separate repository.
All references of `cfd_protocol` were renamed to `maia`.
Patch cargo.toml with a fixed git revision until it gets a public release.
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
Cfd protocol got moved into a separate repository.
All references of `cfd_protocol` were renamed to `maia`.
Patch cargo.toml with a fixed git revision until it gets a public release.
487: Transition to `SetupFailed` if the conract setup failed r=da-kami a=da-kami
Otherwise, the user does not get feedback until restarting the application.
Note: Given what is described in #364 this will be solved in a more complete way. This PR more of a workaround to get user feedback that the contract setup failed. At the moment we don't know until restarting the application which sucks.
Co-authored-by: Daniel Karzel <daniel@comit.network>
485: Remove misleading log r=da-kami a=da-kami
Might have sneaked in during a rebase. This log is just wrong and misleading.
Co-authored-by: Daniel Karzel <daniel@comit.network>
476: Display connection errors to the daemon in the UI r=klochowicz a=klochowicz
Periodically send a keepalive message; if the daemon does not come back with a
response, display a persistent toast notification (at the top of the screen, so
it's harder to miss or confuse).
Notification goes away when the connection to the daemon is re-established.
Fixes#460
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>
475: Oracle attestation should not affect all cfds in monitor r=da-kami a=da-kami
fixes#426
Only the attestation relevant for the cfds, based on the event id, should trigger monitoring for the CET.
We now properly filter the monitoring parameters by event id upon attestation.
Without the filter we ran into the error `No CET for oracle event found`, which is expected when trying to find CETs for an event that does not match.
Since an error in the loop can also have unwanted side effects we wrap it with a `try_continue`.
Co-authored-by: Daniel Karzel <daniel@comit.network>
480: Bump vergen from 5.1.16 to 5.1.17 r=klochowicz a=dependabot[bot]
Bumps [vergen](https://github.com/rustyhorde/vergen) from 5.1.16 to 5.1.17.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/rustyhorde/vergen/releases">vergen's releases</a>.</em></p>
<blockquote>
<h2>v5.1.17</h2>
<ul>
<li>Removed unstable lints from nightly/beta.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="63c5da160c"><code>63c5da1</code></a> version bump for next release</li>
<li><a href="8e0e7c05c2"><code>8e0e7c0</code></a> updated lints</li>
<li>See full diff in <a href="https://github.com/rustyhorde/vergen/compare/5.1.16...5.1.17">compare view</a></li>
</ul>
</details>
<br />
[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=vergen&package-manager=cargo&previous-version=5.1.16&new-version=5.1.17)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting ``@dependabot` rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- ``@dependabot` rebase` will rebase this PR
- ``@dependabot` recreate` will recreate this PR, overwriting any edits that have been made to it
- ``@dependabot` merge` will merge this PR after your CI passes on it
- ``@dependabot` squash and merge` will squash and merge this PR after your CI passes on it
- ``@dependabot` cancel merge` will cancel a previously requested merge and block automerging
- ``@dependabot` reopen` will reopen this PR if it is closed
- ``@dependabot` close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- ``@dependabot` ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Periodically send a keepalive message; if the daemon does not come back with a
response, display a persistent toast notification (at the top of the screen, so
it's harder to miss or confuse).
Notification goes away when the connection to the daemon is re-established.