Too long orderId numbers for ETH/USDT pair

[flashup]

Hello, Binance returns very long numbers for the ETH/USDT orders and JS can't parse it to a number properly.
Usual orderId: 234083988
ETH/USDT orderId: 8389765523229474000
And order update API returns error: code=-2013, message=Order does not exist

The same error in another repo:
ccxt/ccxt#8115

[tiagosiebler]

That's quite an odd finding. When you say JS can't parse it to a number properly, are you seeing an error after getting this order ID from the exchange? Or is this purely when trying to use this order ID in API calls that the exchange rejects this?

If it's the latter, I would definitely report this to binance (either web chat (sorry) or their api telegram https://t.me/binance_api_english ). Unless there's a clear misbehaviour in how the connector interprets this, binance will need to fix that behaviour on the API side.

In the meantime, what you could do is create your own custom order ID:

const customOrderIdForSpotMarkets = generateNewOrderId('spot');
const customOrderIdForUSDMMarkets = generateNewOrderId('usdm');

You can then use that when submitting a new order on the exchange:

    const buyOrderRequest = {
      symbol: "ETHUSDT",
      quantity: buyAmountEth,
      side: 'BUY',
      type: 'MARKET',
      /**
       * ACK = confirmation of order acceptance (no placement/fill information) -> OrderResponseACK
       * RESULT = fill state -> OrderResponseResult
       * FULL = fill state + detail on fills and other detail -> OrderResponseFull
       */
      newOrderRespType: 'FULL',
      newClientOrderId: customOrderIdForSpotMarkets
    };

    console.log(`Submitting buy order: `, buyOrderRequest)
    await client.testNewOrder(buyOrderRequest);
    const buyOrderResult = await client.submitNewOrder(buyOrderRequest) as OrderResponseFull;

Then when doing something like cancelling an order, you'd provide this custom order ID via origClientOrderId instead of providing the exchange-generated order ID. This gives you a bit more control and should get you past this issue in the meantime.

[flashup]

I found the another way to solve this problem in the telegram channel you mentioned above:
https://dev.binance.vision/t/explanation-and-solutions-to-process-long-orderid-u-m-futures-in-js/1186

Ok, at least we have few ways to resolve this problem.

[tiagosiebler]

Damn that's quite messy trying to interfere with number parsing... they return all these numbers that don't need to be strings, as strings...then the one number that's a mess to handle they insist on sending as a number... hopefully they'll look at improving that. Thanks for sharing the link as well!

[sovcik]

Stumbled on this issue today too... This is the orderId I got when short-selling ETHUSDT: 8389765598002322302. I was wondering why I was getting 'non-existing order' error... but then realized, that Javascript rounds it to 8389765598002322000. Really strange.
But suggested workaround using clientOrderId is fully ok.