fix: Calculate max quantity for resizing #2439
Conversation
| -- Before this migration, the taker fee was hard-coded to 0.30%. | ||
| UPDATE positions | ||
| SET order_matching_fees = quantity * (1 / average_entry_price) * 0.0030 where average_entry_price!=0; |
There was a problem hiding this comment.
🤔 This assumes that the position hasn't gone through any resizes before the migration, which is not necessarily true after 2.2.0 was released.
I think we can live with this though.
There was a problem hiding this comment.
Yeah, when I've written it 2.2.0 wasn't released yet. 🙈
There was a problem hiding this comment.
Also, any trade between Friday, 12.04 and now has no order matching fee
There was a problem hiding this comment.
I don't think it's too critical as it will only move the max quantity lower. Do the user might not be able to trade everything, but he won't run into errors.
holzeis
force-pushed
the
fix/max-quantity-with-resizing
branch
2 times, most recently
from
3e09247 to
2337ae6
Compare
| -- Before this migration, the taker fee was hard-coded to 0.30%. | ||
| UPDATE positions | ||
| SET order_matching_fees = quantity * (1 / average_entry_price) * 0.0030 where average_entry_price!=0; |
There was a problem hiding this comment.
Also, any trade between Friday, 12.04 and now has no order matching fee
| // Note, this only works because it is only called from [`updatePriceAndQuantity`], which is only | ||
| // called if the max quantity lock is set. | ||
| _recalculateContracts() { | ||
| contracts = quantity + openQuantity; |
There was a problem hiding this comment.
Wouldn't it be safer to do this from inside _recalculateQuantity(), or whenever quantity is being updated?
There was a problem hiding this comment.
I think it wouldn't be safer, as we want to do this only if the max quantity lock is set. otherwise that would be wrong. As mentioned in the comment, this only works because its only called from the updatePriceAndQuantity which is only called if the maxQuantityLock is set.
There was a problem hiding this comment.
Actually after some testing, it turns out it wasn't working as expected. We achieve the original intention by simply setting the contracts to the maxQuantity after every price update.
| // Note, this only works because it is only called from [`updatePriceAndQuantity`], which is only | ||
| // called if the max quantity lock is set. | ||
| _recalculateContracts() { | ||
| contracts = quantity + openQuantity; |
There was a problem hiding this comment.
openQuantity seems to be always zero?
There was a problem hiding this comment.
It is set when the trade bottom sheet tab is initialised.
| @@ -166,7 +166,6 @@ class TradeBottomSheetConfirmation extends StatelessWidget { | |||
| // Fallback to 0 if we can't get the fee or the margin | |||
| Amount total = | |||
| tradeValues.margin != null ? Amount(tradeValues.margin!.sats).add(reserve) : Amount(0); | |||
| total = total.add(tradeValues.fee ?? Amount.zero()); | |||
The coordinator will not use the order matching fees already collected for past trades when resizing. This has to be considered when calculating the max quantity.
holzeis
force-pushed
the
fix/max-quantity-with-resizing
branch
from
2337ae6 to
d77d4b8
Compare
Calculates the max quantity considering
fixes #2391