HTTP POST响应失败时加密货币交易订单状态及重复下单规避方案问询

Great questions—these are super common pain points when integrating with exchange APIs, especially around reliability and avoiding duplicate orders. Let's break this down step by step:

The short answer is: it's impossible to know for sure without additional checks. The failure could happen at different points in the request lifecycle:

• If the failure occurs before your request reaches the exchange's servers (e.g., DNS failure, network timeout mid-request), the order was never created—so its status is "non-existent".
• If the exchange successfully processed the order, but the response was lost in transit (e.g., network drop after the server sent the response), the order is live/executed, but you didn't receive confirmation.

There’s no way to distinguish these two scenarios just from the failed response alone. That’s why exchange APIs with reliability features (like Client Order IDs) are so critical.

First, a key clarification: HTTP has no built-in rule that requires a server to roll back a POST operation if the client doesn't receive the response. HTTP is stateless, and servers have no way of knowing whether a response was delivered. So you can’t safely retry just because you got an IO error—you risk creating duplicate orders if the original request actually went through.

For exchanges that don’t support Client Order IDs, here are workarounds to mitigate this risk:

• Reverse-verify via account state: After a failed response, check your account’s balance (e.g., if you placed a buy order, verify if your base currency balance increased or quote currency decreased) or recent order history. Look for matches in the timestamp, order amount, and trading pair to confirm if the order was executed.
• Use time-based query filters: Most exchanges let you query orders within a specific time window. After a failed attempt, search for orders created in the last X minutes (match the timeframe of your failed request) using parameters like trading pair, order type, and amount to find potential duplicates.
• Add delays before retrying: Don’t immediately retry a failed request. Give the exchange a few seconds to process the original request (if it did arrive) and update its systems before you attempt to place a new order. This reduces the chance of overlapping requests.
• Accept limited risk as a last resort: If the exchange offers no way to verify order status post-failure, you’ll have to weigh the risk of duplicate orders against the cost of missing a trade. In some cases, you might choose to skip retries entirely for high-value orders.

The most reliable long-term fix is to prioritize exchanges that support Client Order IDs—this lets you uniquely identify each order and safely query its status regardless of response failures.

内容的提问来源于stack exchange，提问作者Yani Ferhaoui