Floating precision in auto-order orderId makes order cancelling impossible

[liuhongyuand]

I noticed there’s precision loss in the orderId I get. When placing orders and querying them via the SDK, Gate’s orderId is a very large number, so precision gets lost and the orderId becomes incorrect, which makes it impossible to cancel the order.

https://www.gate.com/docs/developers/apiv4/en/#create-price-triggered-order-2
https://www.gate.com/docs/developers/apiv4/en/#query-auto-order-list
https://www.gate.com/docs/developers/apiv4/en/#cancel-single-auto-order-2

[tiagosiebler]

Can you provide an example please?

[liuhongyuand]

This is the getFuturesAutoOrders response (id is not equal id_string, and the real orderId is id_string):

    [
      {
        user: 0000,
        trigger: {
          strategy_type: 0,
          price_type: 0,
          price: '0.1339',
          rule: 1,
          expiration: 2592000,
        },
        initial: {
          contract: 'SAND_USDT',
          size: 1083,
          price: '0',
          tif: 'ioc',
          text: '',
          iceberg: 0,
          is_close: false,
          is_reduce_only: true,
          auto_size: '',
          amount: '1083',
          iceberg_amount: '0',
        },
        id: 2016440812132372500,
        id_string: '2016440812132372480',
        trigger_time: 0,
        trade_id: 0,
        trade_id_string: '0',
        status: 'open',
        reason: '',
        create_time: 1769591927,
        finish_time: 1769591927,
        is_stop_order: false,
        stop_trigger: { rule: 0, trigger_price: '', order_price: '' },
        me_order_id: 0,
        me_order_id_string: '0',
        order_type: '',
        in_dual_mode: false,
        parent_id: 0,
        parent_id_string: '0',
        stop_profit_price: '',
        stop_loss_price: '',
        batch_id: '',
        mmr_trigger: { mmr: '', rate: '', trigger_mark_price: '' },
        direction: 'long',
        filled_size: '0',
        broker: 'forthtech',
        finish_as_text: '',
        position_side: '',
        position_side_output: '',
        text_output: '',
        is_splitting: false,
      },
      {
        user: 0000,
        trigger: {
          strategy_type: 0,
          price_type: 0,
          price: '0.1138',
          rule: 2,
          expiration: 2592000,
        },
        initial: {
          contract: 'SAND_USDT',
          size: 1083,
          price: '0',
          tif: 'ioc',
          text: '',
          iceberg: 0,
          is_close: false,
          is_reduce_only: true,
          auto_size: '',
          amount: '1083',
          iceberg_amount: '0',
        },
        id: 2016440803924119600,
        id_string: '2016440803924119552',
        trigger_time: 0,
        trade_id: 0,
        trade_id_string: '0',
        status: 'open',
        reason: '',
        create_time: 1769591925,
        finish_time: 1769591925,
        is_stop_order: false,
        stop_trigger: { rule: 0, trigger_price: '', order_price: '' },
        me_order_id: 0,
        me_order_id_string: '0',
        order_type: '',
        in_dual_mode: false,
        parent_id: 0,
        parent_id_string: '0',
        stop_profit_price: '',
        stop_loss_price: '',
        batch_id: '',
        mmr_trigger: { mmr: '', rate: '', trigger_mark_price: '' },
        direction: 'long',
        filled_size: '0',
        broker: 'oneport',
        finish_as_text: '',
        position_side: '',
        position_side_output: '',
        text_output: '',
        is_splitting: false,
      },
    ]

[tiagosiebler]

You might already be familiar but just in case, this precision loss is a common problem in many programming languages including javascript called floating point precision. Most exchanges tend to use strings for huge number values such as order IDs for this reason. Interesting to hear this endpoint in Gate's API offering is affected.

Where does id_string come from? Was this included in the response automatically or did you add this? It might be that gate have already been informed about this issue and this was their solution, to use the string variable instead. Especially since this issue will be present in many programming languages, not just javascript.

The endpoints for cancelling these types of orders do accept the order ID as a string as well. So if this variable is available to you, this should be the solution here:
https://www.gate.com/docs/developers/apiv4/en/#cancel-single-auto-order-2

Would be curious to hear about id_string though since it is not in the docs.

[liuhongyuand]

Hi, I think it was included in the response automatically.

[tiagosiebler]

I spoke a bit with Gate's team about this. Looks like this is precisely why the "id_string" field was added. I'm not sure yet which endpoints include the id_string field in the response, but we should update our response types for the endpoints we do know about.

So getFuturesAutoOrders definitely returns this "id_string" field, that is the endpoint you were using, right? Apparently the "future.order" websocket channel also supports this field.

Did you see any other endpoints that return this "id_string" field? Let me know and we'll add it.

[liuhongyuand]

I think there might be issues with all the APIs related to order operations. I remember when I tested placing orders, the orderId also had problems.

[JJ-Cro]

We got a response from Gate:

All futures price_order–related REST API endpoints return id_string, including:

POST /futures/{settle}/price_orders
GET /futures/{settle}/price_orders
DELETE /futures/{settle}/price_orders
GET /futures/{settle}/price_orders/{order_id}
DELETE /futures/{settle}/price_orders/{order_id}
PUT /futures/{settle}/price_orders/{order_id}

So, there is part of your answer. Also, seems like all of the requests actually accept string for parameters. We will communicate with them and try to put id_string in response types wherever it is needed.

[benht5am]

There is the same issue with creating basic futures order, see returned object:

export interface FuturesOrder {
    id?: number;

For example, created order has numeric id 36028813724316580, but actual id is "36028813724316572". Unfortunately, there is no id_string field. It is not possible to cancel or fetch order info as the ID is incorrect.

[tiagosiebler]

@benht5am thanks for letting us know. I'm checking with Gate on what the plans are with this endpoint & the int64 floating precision issue.

[tiagosiebler]

There is the same issue with creating basic futures order, see returned object:

export interface FuturesOrder {
    id?: number;

For example, created order has numeric id 36028813724316580, but actual id is "36028813724316572". Unfortunately, there is no id_string field. It is not possible to cancel or fetch order info as the ID is incorrect.

Spoke a bit with Gate. Seems no "id_string" field is planned for this endpoint... that leaves us with two options:

1. Introduce int64-safe number parsing when processing incoming JSON from Gate's API responses. This is one example: https://www.npmjs.com/package/json-bigint
2. Use any other available fields in the meantime. You could include the "text" field with something like a custom order ID, when placing the order. The value used here can also be used to cancel orders: https://www.gate.com/docs/developers/apiv4/en/#cancel-single-order-2

1 makes sense but isn't clean. That's a breaking change that'll affect how all numbers coming from JSON-parsed responses are processed, not just these large ID numbers... it's not ideal and some planning is involved in how to cleanly support that... 2 is the best approach right now, that's the solution you can make use of in the meantime until we have a built-in solution to this.

[benht5am]

Using the text field as client id will work for most use cases. The issue could be with trigger orders as gate.io does not add text field to trigger order notification. Just newly created order id is sent as a number. But maybe there is also some workaround to this.

I am thinking of another solution that would not be a breaking change. The JSON sent by the server could be "preprocessed" by the library and extended with the id_string etc. If eventually gate decides to add _string fields, it would not break either. E.g.:

const text = await response.text()
const fixedText = fixIncorrectId(text);
const data = JSON.parse(fixedText)

[tiagosiebler]

Thanks for pointing that out. I've informed my contacts at Gate on this, with hope it adds incentive to string-typed IDs (or simply including the "text" field there).

The pre-processing is definitely an idea too. I'm cautious of rolling out blanket pre-processing text before parsing as JSON in case this becomes fragile and risks bigger issues. Perhaps we can do this with an option that makes it easy to opt out, or an alternative would be exposing something like this:
https://github.com/tiagosiebler/binance/blob/v3.1.0/examples/WebSockets/ws-custom-parser.ts#L21-L25

In our Binance SDK, we rolled out a place you can define your own JSON parsing logic. In this example it is as you suggested - pre-processing known fields with regex, to ensure these are processed as strings when the parser kicks in. Need to investigate how to override the json parser used by axios (it's currently handled automatically). I'm sure there's a way, axios is mature enough...