Sandbox: fills are applied multiple times to the same limit order #1639
Comments
|
I've pasted the logs specifically for order O-20240511-1933-001-000-3601. I am wondering whether there is some priority queue mechanism in place to process order events ahead of data events? Perhaps multiple ticks are triggering the fills, the fill events are then processed too late when other fill events have already been created. |
|
Yes, this was also my thought that multiple ticks are triggering fills causing an overfill. Its the same overall cause as the last error, that we now have this real-time component of the system operating outside a deterministic loop. |
|
Separately, the leaves quantity should never be allowed to underflow like that as well. [edit] I see what was happening there - it became negative and was then cast to an unsigned int64 in the exception message, so at least the invariant was upheld there. |
|
Yes, exactly. We probably need a mechanism that order fills are processed on priority. Not sure how much impact that has on the current code base. |
|
So the issue here is that a real matching engine would keep track of exactly how much of an order has been filled, where as the backtest matching engine Nautilus uses allows this to be tracked by the order object itself, and execution engine - essentially all "client side". This wasn't a problem just for backtesting, but has become a problem for sandbox mode. I've added a fill quantity cache to the matching engine now so that once the entire size has "cached/pending" fills, no more fills will be processed even as additional ticks may be arriving before the execution engine has a chance to apply the events ff7c338. Lets see how this goes. |
|
Amazing! Currently compiling and about to start a new test, but won't be able to let it run for a long time. This evening I'll let it run overnight. |
cjdsellers
changed the title
|
The error hasn't occured during the latest test, so closing. Thanks for making the fix! |
|
Reopening as the error occured again. This is on the develop branch with git commit ee1c9b2 |
|
Looking at the logs, I think the The first one should be a complete fill, but the second one should be a partial fill as the size of the limit order is 0.002. |
|
So thinking a bit more on this, what is perhaps happening is that 2 fill events are passed through the cache fills check resulting in an overfill. Maybe the second fill event needs to be modified with a smaller quantity. |
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
Expected Behavior
Only 1 fill is created for the limit order client_order_id=O-20240511-1933-001-000-3601.
Actual Behavior
During a sandbox live trading test, multiple fill events are created for an existing limit order.
Steps to Reproduce the Problem
Specifications
nautilus_traderversion: develop branch, git commit ee47d5eThe text was updated successfully, but these errors were encountered: