Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Move past multiple orders in Filling state #1775

Merged
merged 7 commits into from
Jan 3, 2024
Merged

Move past multiple orders in Filling state #1775

merged 7 commits into from
Jan 3, 2024

Commits on Jan 3, 2024

  1. chore(app): Display rejected and filling states in frontend 

    I don't see any benefit in dumbing down this model for the frontend.
And it can create confusion when debugging issues.
    @luckysori
    luckysori committed Jan 3, 2024
    Configuration menu
    Copy the full SHA
    bdd727b View commit details
    Browse the repository at this point in the history

  2. chore(app): Fix typo

    @luckysori
    luckysori committed Jan 3, 2024
    Configuration menu
    Copy the full SHA
    b8b0e16 View commit details
    Browse the repository at this point in the history

  3. fix(app): Ensure that we can only have one Filling Order at a time 

    If no new `Order`s can be submitted until the current `Order` in
`Filling` is either moved to `Filled` or `Failed`, we ensure that we
cannot have multiple `Order`s in `Filling` at the same time.

This is important because this was supposed to be an invariant which
we were not upholding.
    @luckysori
    luckysori committed Jan 3, 2024
    Configuration menu
    Copy the full SHA
    e9a1f27 View commit details
    Browse the repository at this point in the history

  4. fix(app): Handle possibility of multiple orders in Filling 

    The previous patch attempted to prevent the situation from happening,
but we have already encountered instances where this has happened.

To handle them, we choose to:

- Take the _oldest_ `Order` in `OrderState::Filling`, because it is
the one that was never resolved in the first place. This order is the
one most likely to match the unfinished update to the subchannel.

- Discard all other `Order`s in `OrderState::Filling`, because the
user should not have been able to create them anyway.
    @luckysori
    luckysori committed Jan 3, 2024
    Configuration menu
    Copy the full SHA
    c53a467 View commit details
    Browse the repository at this point in the history

  5. fix(app): Succeed order_failed even if order does not exist 

    The function `order_failed` does some cleanup when an order could not
be filled. But if the DB does not know about this order for some
reason, there isn't really anything to clean up in terms of orders and
the rest of the cleanup should continue.
    @luckysori
    luckysori committed Jan 3, 2024
    Configuration menu
    Copy the full SHA
    7e892fb View commit details
    Browse the repository at this point in the history

  6. chore(app): Format order_filling

    @luckysori
    luckysori committed Jan 3, 2024
    Configuration menu
    Copy the full SHA
    20ba2b5 View commit details
    Browse the repository at this point in the history

  7. Merge branch 'main' into fix/two-open-orders

    @luckysori
    luckysori authored Jan 3, 2024
    Configuration menu
    Copy the full SHA
    363ca37 View commit details
    Browse the repository at this point in the history