-
Notifications
You must be signed in to change notification settings - Fork 78
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.
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
Fix: zero amount order bug #1816
Conversation
} | ||
|
||
#[test] | ||
fn when_apply_over_smaller_inverse_swap_but_math_precission() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do not really need this test if we have the pallet-swaps
tests. But I wanted to force a use case from FI PoV. We can finally remove it once we're sure it's fully solved.
49c0dde
to
c21a170
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!! @lemunozm do you think this fix has to live here or we could think about fixing it on the pallet-order-book
side?
I am also not sure why having a zero order lead to a missing FI state. Do you know the reason for that or in general explain what the issue was? I mean pallet-order-book
does fulfill zero orders, right?
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1816 +/- ##
==========================================
+ Coverage 48.53% 48.56% +0.03%
==========================================
Files 167 167
Lines 13314 13320 +6
==========================================
+ Hits 6462 6469 +7
+ Misses 6852 6851 -1 ☔ View full report in Codecov by Sentry. |
I've added a couple of test for cancel zero amount orders and fulfill zero amount orders and they work fine. So from My reason for putting this in
Do you mean to this error right? I'm pretty sure it is because when creating a zero-order, from FI PoV, the swap is fully done, and it detects it can clean the associated info. So later, when you fulfill the zero order, you can not find such a state. This should no longer happen because we're blocking the creation of zero-amount orders now. |
Makes sense! Thanks |
* add tests that fail and shouldn't * add fix * add extra tests
* fix: looser is_local_representation * tests: fix after changing setup * Fix: zero amount order bug (#1816) * add tests that fail and shouldn't * add fix * add extra tests --------- Co-authored-by: Luis Enrique Muñoz Martín <lemunozm@gmail.com>
Description
There are two casuistics where an order can contain a zero amount. Such an order can not be closed, and theoretically, it should not exist.
Q: Should we allow to close zero orders even though they should not be possible now?