Order Status of Queries After Cancellation

Advanced Trade API
1

Hi, I’m in the process of testing a Python client, and have found that querying an order that I’ve successfully cancelled returns conflicting status and cancel messages. A cancel request succeeds with the following JSON response:

2023-01-17 07:00:33,619 -2198716 -INFO- COINBASE RESPONSE TEXT (POST 200):
{
    "results": [
        {
            "success": true,
            "failure_reason": "UNKNOWN_CANCEL_FAILURE_REASON",
            "order_id": "aa...6d"
        }
    ]
}

And a subsequent query of the order (synchronously), returns a query message with "status": "OPEN" and "cancel_message": "User requested cancel", as below:

2023-01-17 07:00:33,727 -2198716 -INFO- COINBASE RESPONSE TEXT (GET 200):
{
    "order": {
        "order_id": "aa...6d",
        "product_id": "USDT-USD",
        "user_id": "...",
        "order_configuration": {
            "limit_limit_gtc": {
                "base_size": "10",
                "limit_price": "0.95",
                "post_only": true
            }
        },
        "side": "BUY",
        "client_order_id": "...",
        "status": "OPEN",
        "time_in_force": "GOOD_UNTIL_CANCELLED",
        "created_time": "2023-01-17T12:00:33.248230Z",
        "completion_percentage": "0",
        "filled_size": "0",
        "average_filled_price": "0",
        "fee": "",
        "number_of_fills": "0",
        "filled_value": "0",
        "pending_cancel": true,
        "size_in_quote": false,
        "total_fees": "0",
        "size_inclusive_of_fees": false,
        "total_value_after_fees": "0",
        "trigger_status": "INVALID_ORDER_TYPE",
        "order_type": "LIMIT",
        "reject_reason": "REJECT_REASON_UNSPECIFIED",
        "settled": false,
        "product_type": "SPOT",
        "reject_message": "",
        "cancel_message": "User requested cancel"
    }
}

This is at the very least unexpected, but at least pending_cancel is true. Can we assume an order will be cancelled if the cancellation request returns success, and a query of returns pending cancel as true?

I’ve also subsequently run into "error_details": "order with this orderID was not found" when querying an order I’ve just made (again, synchronously). Can an engineer elaborate on what the expected behavior of the matching engine is, and what a recommended way of handling it is? Surely we shouldn’t poll get_order until the matching engine realizes our confirmed order exists?

Thanks,
Brendan

2

Hi @brendano257 ! We appreciate you sharing your thoughts and API experience here in the forum. Regarding your concern when querying the order and obtaining an “open” status when subsequently queried after cancelling the orderID is reasonable for the fact that there is likely a small delay time for the propagation of the cancelled status through Coinbase system, thus we encourage you not to poll immediately until the status has been changed, which same goes with creating an order right after a cancellation/status update of another orderID.

To answer your question, Can we assume an order will be cancelled if the cancellation request returns success, and a query of returns pending cancel as true?, yes, if your call returned a 200 OK response then your orderID must be cancelled, pending_cancel: true also indicates that the cancellation is under way.

With reference to your concern, I’ve also subsequently run into " error_details" : “order with this orderID was not found” when querying an order I’ve just made, can you kindly provide the affected orderID so our internal teams can further investigate your concern. We’ll wait for your response.

Have a great day!

3

Hi @PochiiKun, the order in question was “c54167ce-0d81-46cb-bdc2-daeb46eeddcb”, which I synchronously placed and then queried, and got an orderID was not found response.

If it’s possible we can cancel or place an order, and a subsequent cancel, query, or order can fail because the matching engine has confirmed the order/cancel with me, but not itself…how can I determine a safe time to wait, or an effective retry strategy? Any waiting is not guaranteed to always be enough, nor is it an effective trading strategy to wait around, and retries are costly for both the matching engine and my own rate limits and complexity.

4

Hi @brendano257! Thank you for providing the information we need. We will communicate this for you with our team to see how we can best assist. We’ll get back to you once we have more information. Keep in touch!

1 Like
5

Hi @brendano257! Thank you so much for your patience while we address your query. With reference to your concern, I’ve also subsequently run into " error_details" : “order with this orderID was not found” when querying an order I’ve just made, please know that our internal teams are still hard at work to resolve this concern. We will let you know once we have an update.

With regards to your other concern regarding waiting time for querying order status immediately after cancelling and/ or creating the order, if the order can’t be found, then no retry is needed just yet. If the order fails to place asynchronously, it will still show up in the Get Order endpoint, just with a failed status. Same for cancel, as long as pending_cancel is true, you shouldn’t retry the cancel just yet.

We hope this helps!

6

Hi @Anonymouse, thanks for the update! My concern with a retry was more with querying after making an order, or placing a new order immediately after a cancel, which can fail when the matching engine still acts as though the funds from the canceled order are unavailable. Querying immediately after placing is an issue because the order API doesn’t return full details (though it now returns order_configuration at least) when an order is placed, so a query after making the order is necessary for me to fully represent the order on my side. For instance, order confirmations from create_order don’t return an explicit status, timestamp (!!), type, or any of the other information like number of fills, fees, etc. Some of these can maybe be assumed to be 0, but that’s not necessarily true in the case of an order that fills immediately as a taker.

Thanks again,
Brendan

7

Hello @brendano257! After a brief investigation with the team regarding this, we found out that this is a bug. Please be informed that the Advanced Trade API team will be prioritizing and will begin to work on it. Your patience is highly appreciated. Have a great day ahead! :smiley:

8

Hi @brendano257! Just to ensure that we are on the same page with you as we work about this matter internally with our teams, can you please confirm which API endpoint you are actually calling for when you experienced the issue of trying to look up the open order immediately after creating it and getting “order not found” error?

We will await your response. Thank you and have a nice day! :sunny:

1 Like
9

Hi @ereeca15, sorry for the delay. This was specifically calling get_order using an ID that was just given to me via a response from place_order.