Issue with cancelling open orders

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