I am seeing what appears to be an issue with cancelling open orders (note this is happening with FUTURES on Testnet).
A Post-only order (TimeInForce is GTX) is submitted using a SYNCHRONOUS rest client (so the code waits for the response from Binance). In the event the response has an OrderStatus of NEW, my expectation is that the order is in the order book and therefore Binance knows about the order. Depending on some additional checks (all of which occur in the same thread with nothing from another thread making any modifications) at times I decide to immediately cancel the order (submitting another SYNCHRONOUS request using the client). However, the response for the cancel causes an exception to be thrown, with the message unknown order sent. I am cancelling the order using the same clientOrderId that was used to place the order. And in fact the order is being cancelled (in the Binance GUI Order History I can see the order and a status of Cancelled). So why is the API throwing an exception, when the order ought to be available if I have received a response from a synchronous call, and in fact is being cancelled successfully.
The original order (Status NEW) appears eventually in the USER_DATA_UPDATE stream, which is expected. What is not expected is the exception when the order is cancelled by through the API.
I would appreciate clarification of when an order is in fact known to Binance (and therefore available to be cancelled without an exception being thrown), If this is by chance another artifact of Testnet behavior, that too is useful information.
Thanks,
Jack
Here is representative timing detail for the cancellation exception issue. Note that the xxx-01828-1 order was entered and then received as an ORDER_TRADE_UPDATE event. Almost 3 seconds later it was cancelled but the request threw an exception. HOWEVER, the order was cancelled and the event appeared in the ORDER_TRADE_UPDATE stream. Logging on the local machine is asynchronous so the logging lines get queued - in program flow, order 01791-1 was submitted; during processing of the new order response, the cancellation of order 01828 was submitted. That submission generated the exception, which was logged. Very quickly thereafter data from the ORDER_TRADE_UPDATE stream was processed - NEW order 01797 appears, then the Cancellation of order 01828.
| Activity | Log Time Stamp (Local Computer) | Client Order Id | Event Time | Event Time Formatted | Comments |
|---|---|---|---|---|---|
| Order Submitted through API | 2021-12-12 02:03:22.986Z | 020321787Z-3-01288-00481-1 | 1639274603838 | 2021-12-12 02:03:23.838Z | Time is UpdateTime returned in response payload for NEW order placed through synchronous API client |
| ORDER_TRADE_UPDATE - NEW | 2021-12-12 02:03:22.986Z | 020321787Z-3-01288-00481-1 | 1639274603841 | 2021-12-12 02:03:23.841Z | Time is Event Time in OrderUpdate event |
| ORDER_TRADE_UPDATE - FILLED | 2021-12-12 02:03:35.911Z | 020321787Z-3-01288-00481-1 | - - - | ||
| Order Submitted through API | 2021-12-12 04:44:02.008Z | 044400709Z-1-04186-01828-1 | 1639284242890 | 2021-12-12 04:44:02.890Z | Time is UpdateTime returned in response payload for NEW order placed through synchronous API client |
| ORDER_TRADE_UPDATE - NEW | 2021-12-12 04:44:02.008Z | 044400709Z-1-04186-01828-1 | 1639284242892 | 2021-12-12 04:44:02.892Z | |
| Order Cancelled through API | 2021-12-12 04:44:04.534Z | 044400709Z-1-04186-01828-1 | - - - | EXCEPTION (UNKNOWN ORDER SENT) | |
| Order Submitted through API | 2021-12-12 04:44:04.534Z | 044401737Z-3-04188-01797-1 | 1639284244206 | 2021-12-12 04:44:04.206Z | Time is UpdateTime returned in response payload (This order triggered cancellation of 044400709Z-1-04186-01828-1) |
| ORDER_TRADE_UPDATE - NEW | 2021-12-12 04:44:04.534Z | 044401737Z-3-04188-01797-1 | 1639284244208 | 2021-12-12 04:44:04.208Z | Time is EventTime returned in response payload for NEW order placed through synchronous API client |
| ORDER_TRADE_UPDATE - CANCELED | 2021-12-12 04:44:04.534Z | 044400709Z-1-04186-01828-1 | 1639284244815 | 2021-12-12 04:44:04.815Z | DESPITE REPORTED EXCEPTION THE ORDER WAS CANCELLED |
Eventually I want to submit cancellations asynchronously, but first I have to have confidence that actions are happening and being recorded as I expect.
Thanks.
FWIW I hit on this topic because Im seeing similar behavior with the Binance Spot API (on testnet). ie Cancelling valid, recent orders sometimes fails with an error unknown order sent .
Experimentally, it seems to error if the to-be-cancelled order has been filled. Given the async interactions with the market, it is possible that the client tries to cancel concurrently with the order filling, so receiving this error response for a filled order can be ignored I think…
Yes, I have the same problem on spot when try to cancel an order which gets filled same time. AFAIK, Binance shall return some other code than the misleading “Unknown order sent”. Eg. “Order already done”. To allow the client to distiguish between a real error and this situation which is actually a normal order flow (order can be filled while the client trying to cancel it - this is OK)
In the classical asyncronuis order flow (like FIX) we don’t get the cancel reply immediately but first the broker sends us all the fills and then they send either cancel ack or cancel reject if the order is fully filled. However, in REST API we receive the relpy immediately which means that we can NOT be sure there were no fills for the order during our cancel request. Moreover, after we successfully cancelled the order we must request for the latest fills (or be ready to receive them from the WS connection). Only after applying that fills we may “forget” the cancelled order