OCO orders status: EXPIRED + NEW

Checking OCO orders to see if they executed, I noticed that from time to time I get an unexpected situation where I get a combo of order-status EXPIRED + NEW.
In these cases, my program checks 3 times 0.5s later. It happens that after that time, status is still EXPIRED + NEW. Checking a few hours later and it finally closed: EXPIRED + FILLED.

Any idea if this is “normal”?
What could be the cause (could it be partial fill?)?
How fast should I expect Binance to have both orders updated to latest status?

Thanks in advance :slight_smile:

(I use python-binance, if that helps)

If one order in the OCO order that is partially filled, the status is PARTIALLY_FILLED and the other one will be EXPIRED. Please print out the OCO order details and see what’s the status of both orders.

I got another example during the night. Here are the order statuses:

symbol  orderId  orderListId           clientOrderId           price  \

0 BTCUSDT xxxxxxx aaaa ______________________ 45376.74000000
1 BTCUSDT yyyyyyy aaaa ______________________ 43819.69000000

  origQty executedQty cummulativeQuoteQty   status timeInForce  \

0 0.01000000 0.00000000 0.00000000 EXPIRED GTC
1 0.01000000 0.00000000 0.00000000 NEW GTC

          type  side       stopPrice  icebergQty           time  \

0 LIMIT_MAKER SELL 0.00000000 0.00000000 1644436981621
1 STOP_LOSS_LIMIT SELL 43908.67000000 0.00000000 1644436981621

  updateTime  isWorking origQuoteOrderQty  

0 1644440538123 True 0.00000000
1 1644440538123 True 0.00000000

(These 2 orders are now complete, the “NEW” one was FILLED)

Is there a specific way to check OCO orders? Because at the moment I just check each of the 2 orders and compare their statuses.

Any idea? :slight_smile: Thanks!!

Anyone has an idea? Thanks!

When the stopPrice of the OCO order was triggered, it closed your LIMIT_MAKER (EXPIRED) and opened a new order STOP_LOSS_LIMIT. Since the last one is a limit order, it’s expected for it to not be filled immediately, that’s why it’s in NEW status.