Binance could not find order during closing request, but executed it 4 hours later

[movy]

Thanks for great driver once again, it's super stable and fast!

The bug is not driver's, but rather on Binance side it seems.

The subject is self descriptive -- I'm trying to cancel an order in fronting attempt, cancellation returns "code":-2011,"msg":"Unknown order sent.", so I move on and successfully open and then close my position with another order, but 4 hours later the order in question (633327755481579400) is executed, re-opening my position again (totally undesired).

This is first time I ever encountered such sequence I think, and it happened during last night's blood bath, so binance was quite busy. Any way to escalate with them?

Logs:

[02-20 22:00:38.001]: Order placed {"633327755481579400":{"orderId":633327755481579400,"symbol":"RSRUSDT","status":"NEW","clientOrderId":"x-15PC4ZJyLO:0.002773:1hF13JaViLa:fC","price":"0.002773","avgPrice":"0.00","origQty":"46881","executedQty":0,"cumQty":"0","cumQuote":0,"timeInForce":"GTC","type":"LIMIT","reduceOnly":false,"closePosition":false,"side":"BUY","positionSide":"BOTH","stopPrice":0,"workingType":"CONTRACT_PRICE","priceProtect":false,"origType":"LIMIT","priceMatch":"NONE","selfTradePreventionMode":"NONE","goodTillDate":0,"updateTime":1708466437663,"tradeTime":1708466437663,"tradeId":0,"originalQty":46881,"orderPrice":0.002773,"averagePrice":0,"stopPriceWorkingType":"CONTRACT_PRICE","executionType":"NEW","realizedProfit":0,"lastFilledQty":0,"lastFilledPrice":0,"commissionAmountUSDT":0,"commissionAmount":0,"commissionAsset":"USDT","tradeMakerSide":false,"bidsNotional":130.001013,"askNotional":0}} BUY x-15PC4ZJyLO:0.002773:1hF13JaViLa:fC 633327755481579400 1708466437663 NEW
[02-20 22:00:40.107]: 🔝 Fronting BUY RSRUSDT order x-15PC4ZJyLO:0.002773:1hF13JaViLa:fC 633327755481579400
[02-20 22:00:40.201]: /cancelMultipleOrders  {"symbol":"RSRUSDT","orderIdList":[633327755481579400]}  response: [{"code":-2011,"msg":"Unknown order sent."}]

4 hours later:

[02-21 02:26:20.536]: 🦾 Handling orderData: {"updateTime":1708482380155,"tradeTime":1708482380155,"symbol":"RSRUSDT","clientOrderId":"x-15PC4ZJyLO:0.002773:1hF13JaViLa:fC","orderId":633327755481579400,"tradeId":252732724,"side":"BUY","positionSide":"BOTH","originalQty":46881,"orderPrice":0.002773,"averagePrice":0.002773,"stopPrice":0,"stopPriceWorkingType":"CONTRACT_PRICE","executionType":"TRADE","status":"FILLED","realizedProfit":0,"timeInForce":"GTC","type":"LIMIT","origType":"LIMIT","lastFilledQty":46881,"lastFilledPrice":0.002773,"executedQty":46881,"commissionAmountUSDT":0.023413852800000003,"commissionAmount":0.00006624,"commissionAsset":"BNB","tradeMakerSide":true,"reduceOnly":false,"closePosition":false,"priceProtect":false,"bidsNotional":0,"askNotional":0,"cumQuote":0}
[02-21 02:26:20.537]: ✔️✔️ RSRUSDT LIMIT BUY qty 46881, comm $0.023414 (BNB) x-15PC4ZJyLO:0.002773:1hF13JaViLa:fC

[tiagosiebler]

Hi, glad the SDK is helping you! Because of the very long order number, I think this might be the same issue as the one described in #208. It's primarily related to the fact the order ID is stored as a number and the value itself is huge.

So one workaround is using a custom order ID when submitting the order, so you're in control of how the order ID looks (the custom one) and you can control your orders using the custom order ID instead. Take a look at the linked issue, there's some convenience methods that can help.

I've also read more recently that apparently you can send order ID as a string (even if the docs say it should be a number). Could you try this? If the cancel and batch cancel methods accept order IDs as strings, would be good to update the interfaces to reflect that.

[movy]

Thanks for recommendations, will give it a go with my bot.

[movy]

Can confirm that the problem is exactly as described in #208, and casting orderId as a string works:

[02-29 17:00:12.763]: /cancelOrder {"symbol":"OMGUSDT","orderId":"16296932053"}  
response: {"orderId":16296932053,"symbol":"OMGUSDT","status":"CANCELED","clientOrderId":"x-15PC4ZJyLO:0.8976:1hJ31HeWaSl:iQkQ","price":"0.8981","avgPrice":"0.00","origQty":"70.2","executedQty":"0.0","cumQty":"0.0","cumQuote":"0.00000","timeInForce":"GTC","type":"LIMIT","reduceOnly":false,"closePosition":false,"side":"BUY","positionSide":"BOTH","stopPrice":"0.0000","workingType":"CONTRACT_PRICE","priceProtect":false,"origType":"LIMIT","priceMatch":"NONE","selfTradePreventionMode":"NONE","goodTillDate":0,"updateTime":1709226012763}

HOWEVER, sending strings for cancelMultipleOrders is not supported??

/cancelMultipleOrders FOOTBALLUSDT: 38.408ms
[03-01 04:00:18.583]: {"symbol":"FOOTBALLUSDT","orderIdList":["1988124542"]}: {"code":-1130,"message":"Data sent for parameter 'orderidlist' is not valid.","body":{"code":-1130,"msg":"Data sent for parameter 'orderidlist' is not valid."},"headers":{"date":"Fri, 01 Mar 2024 04:00:18 GMT","content-type":"application/json","content-length":"74","connection":"close","server":"Tengine","x-mbx-used-weight-1m":"7","x-response-time":"2ms","access-control-allow-origin":"*","access-control-allow-methods":"GET, POST, PUT, DELETE, OPTIONS"},"requestUrl":"https://fapi.binance.com/fapi/v1/batchOrders?symbol=FOOTBALLUSDT&orderIdList=%5B%221988124542%22%5D&timestamp=1709265618542&recvWindow=2001&signature=ffb98402f7572b2d1b80e5de93085954900eeffb414fe753eb61a1c133bff347","requestOptions":{"recvWindow":2001,"syncIntervalMs":3600000,"strictParamValidation":false,"disableTimeSync":true}}

This is bananas...

So maybe worth checking number of digits and forcefully converting orderId to a string would help? Or somehow very clearly specifying it in the docs and types definitions, as some popular pairs have order ids in quintillions, so this problem can be quite common. I think I spent several days trying to figure why my fronting sequence was so wonky...

[tiagosiebler]

Yeah I've voiced this multiple times to binance and it's a common complaint in other languages too. Not sure why this is sent and expected as a number. I had hoped since one endpoint already supports strings the others would too, but I guess not. I'll ask them again about it.