app: ignore zero-quantity book_order updates #1543
Conversation
8d5b7df to
a356031
Compare
|
I swear @JoeGruffins just commented about cancel orders being a related issue, but I cannot find it. Also might be related is that I often see 0 qty market buy orders in the table and I have a feeling they are not actually trade orders, but cancels that somehow got in. Something about the zero-values for an order and the flags for force, sell, etc.? |
|
In testing the expiry PRs I put up, I managed to get a ghost buy order on the depth chart. I couldn't tell if it appeared after the match or when the revoke_order happened. Might try it again. |
a356031 to
f6cd40f
Compare
|
I've come back to this a couple of times to try to figure why this helps, and I still have no idea. But it does seem to prevent the issue for me. |
|
I've been saving the loadbot go.sum update for #1656 if that's alright with you |
| @@ -23,6 +23,7 @@ export default class OrderBook { | |||
|
|
|||
| /* add adds an order to the order book. */ | |||
| add (ord: MiniOrder) { | |||
| if (ord.qtyAtomic === 0) return | |||
There was a problem hiding this comment.
I say let's go with it, but in the name of figuring this out, how bout a console log with info about the order, maybe just the whole json ord, to help figure out why it's here?
There was a problem hiding this comment.
There are a lot of these.
There was a problem hiding this comment.
You mean it happens frequently or there are a lot of places in the code?
If it happens frequently, what are they? Cancels?
There was a problem hiding this comment.
They are orders that are booked, match partially (generating a update_remaining), then finish matching in the same epoch. By the time the update_remaining notification is generated by BookRouter, the order's Remaining value is 0. It's of little consequence in most places because an unbook_order notification is sent immediately after. I've put a little cache with a timer in place to make sure that the unbook_order comes through for every zero-qty order within a second or so, and they all do. But still for some reason, if not ignored, a zero-qty order will end up persisting on the book somehow, screwing up the chart.
There was a problem hiding this comment.
I was trying to repro with something very similar. Two lot order on book, matches with 1 lot taker, hitting handleUpdateRemainingRoute (which could use an as RemainderUpdate I think), and following with a cancel in the same epoch hitting handleUnbookOrderRoute, so very similar to what you described. Still couldn't make this ord.qtyAtomic condition hit in this add function. 🤷♂️
f6cd40f to
1c0eb75
Compare
1c0eb75 to
1744aed
Compare
|
You can watch loadbot trade on compound and enable the logger in the console. enableLogger('zeroqty', true) |
I've been chasing down the residual orders in the front-end order book and depth chart. The orders that we see are zero-quantity orders that appear to be related to orders that are booked and unbooked on the same match cycle. In that case, we receive a
book_orderupdate followed by anunbook_orderupdate. Thebook_orderupdate contains aBookOrderNotewith a zero-quantity order, because by the time theorder.LimitOrdergets translated byBookRouter, theRemainingis already zero.I still haven't figured this out. I've put feelers around to try to catch a zero-quantity
book_orderupdate with no subsequentunbook_orderupdate, but I haven't seen one yet, even though I still see residual orders.Oddly, these leftover orders only appear on the buy side.
This PR is here just to display a crude fix and for discussion. I've been banging my head against the wall on this one, and I need to switch gears.
The crude fix is to simply ignore zero-quantity orders in
OrderBook.add. We already ignore unmatchedunbook_orderupdates.