If an order request times out, can the agent send it again? Only after it can establish whether the broker accepted the first request. A timeout describes what the client observed, not what happened at the venue.
Consider an unattended strategy submitting a limit order for 200 shares at $50. The client waits two seconds, gets no response and retries.
The first request may already be live. If both requests fill, the strategy owns 400 shares, or $20,000 of exposure, rather than the intended $10,000. Idempotency and retries need to be designed around that uncertainty.
The timeout that creates two orders
Separate intent from transmission
Represent the intended trade as a durable record before making the network call. Give it a unique identifier, store the symbol, side, quantity, limit price, strategy decision and creation time, then mark the request as submitted.
A network retry must reuse that intent and identifier. It must not create a fresh order record just because a response was lost.
This is not the same as guaranteeing exactly-once delivery. A client and broker cannot generally prove that a message crossed the network exactly once. The practical goal is effectively-once handling: preserve one intent, prevent repeated submissions from creating repeated orders, then reconcile the broker's state.
Make the failure concrete
In the 200-share example, the broker accepts the order, fills 80 shares and sends an acknowledgement that never reaches the client. The client times out. A blind retry could create another 200-share order while the original 120 shares remain open. The agent might then buy up to 320 more shares, reaching 400 shares in total.
With a stable identifier, a repeated submission can return the existing order if the broker supports idempotent requests. If it does not, the client must first search broker orders and executions for that identifier. It should not assume that an HTTP error or closed socket means the order was rejected.
Give each intent a durable identity
Use an identifier the broker recognises
Generate a client order ID before submission. A typical format combines a strategy or account prefix with a compact unique value, such as a UUID. Keep it within the broker's documented length and character limits. Persist it across process restarts, and never reuse it for a different trading decision.
Check the exact semantics in the API documentation. Some venues treat a repeated ID as a request to return the existing order. Others reject the duplicate, limit the ID's scope to a session, or retain it only for a finite period. A client order ID is useful for searching and reconciliation, but does not by itself make a submission idempotent.
Persist before sending
Write the intent and its identifier to durable storage before sending the request. A database uniqueness constraint on the intent ID prevents two workers from creating separate records for the same decision. An outbox pattern can then publish the stored request, with delivery state updated independently of the strategy process.
Store the broker account, instrument, side, order type, quantity and price alongside the ID. On restart, load unresolved intents and inspect broker state before acting. Do not rebuild IDs from the current time or regenerate them after a crash. For further testing of agent order flows, Agentic Trading Index paper trading can help exercise these recovery paths without live capital.
Retry by state, not by exception
Classify the response before deciding what to do. A clear validation rejection is not a transport failure. A 429 rate limit response usually calls for waiting. A timeout after request transmission leaves the outcome unknown. Treating all three as the same retry case can turn a recoverable connection problem into an unintended position.
- Accepted or acknowledged: record the broker order ID and poll or subscribe for updates. Do not submit again.
- Rejected with a definitive reason: record the rejection. A corrected order is a new intent with a new ID.
- Unknown after timeout or connection reset: query by client order ID, inspect open orders and executions, and only then decide whether another submission is safe.
- Rate limited or temporarily unavailable: honour Retry-After where supplied. Use a capped delay with jitter to avoid many workers retrying together.
Typical operational ranges below are starting points, not venue guarantees. Broker documentation and observed behaviour should set the actual limits.
| Condition | Typical wait or window | Typical handling |
|---|---|---|
| Request timeout after submission | 1 to 10 seconds before lookup | Reconcile by client ID before resending |
| 429 rate limit response | 100 milliseconds to 2 seconds if no header is supplied | Follow Retry-After, then retry within a capped budget |
| Temporary 5xx response | 1 to 10 seconds between attempts | Two to four attempts over 10 to 30 seconds, only with safe idempotency |
Keep retry budgets short enough that an old signal cannot become a stale order. For a fast intraday strategy, a 20-second recovery window may already outlive the signal. For slower execution, a longer window may be acceptable, but the order still needs a price and exposure check before any resubmission.
Reconcile fills before releasing the agent
Order state is not binary. A broker may report new, partially filled, filled, cancelled or rejected, and updates can arrive late or out of order. Track cumulative filled quantity and remaining quantity separately. In the example, an 80-share fill means the remaining quantity is 120, not 200. The strategy's target position and risk limits must include those 80 shares immediately.
Set a rule for unresolved orders. If a lookup by client ID finds an open order, continue monitoring it. If it finds a terminal order, record its final fills and status.
If the broker cannot find the ID, repeat the query after a short wait and inspect account executions. Only submit again when the evidence supports the conclusion that no live or filled order exists.
Before a retry, recheck the strategy signal, limit price, maximum order size and account exposure. A retry should not revive an order after the market has moved or a kill condition has fired. Cancel and replace operations need their own identities and state tracking, since a cancel acknowledgement can also be delayed while the original order continues to fill.
- Persist every submission attempt, response, lookup and fill with timestamps and the same intent ID.
- Alert or halt new orders when an intent stays unknown beyond the configured recovery window.
- Test timeouts after broker acceptance, partial fills before acknowledgement, duplicate requests and process restarts in paper trading.
Run one fault-injection test this week: accept an order in the test venue, drop its acknowledgement, and verify that the agent reconciles the original order without creating another one.
Frequently Asked Questions
What does idempotency mean in order placement?
An idempotent submission can be repeated without creating a second order for the same trading intent. Broker support varies, so a client order ID may need to be combined with order lookups and reconciliation.
Should an agent retry an order after a timeout?
Not until it checks whether the broker accepted the request. Search by client order ID and inspect open orders and executions first. If the result remains unknown, pause or escalate rather than submit a fresh order blindly.
Is a client order ID enough to prevent duplicate orders?
No. Some APIs use the ID to deduplicate submissions, while others only expose it as a search field or enforce limited retention. Confirm the broker's documented behaviour and test duplicate requests in a non-live environment.
How should an agent handle a partially filled order during a retry?
Record the cumulative filled quantity and remaining quantity from broker state. Do not resubmit the original full quantity. Recheck the target position, signal validity and risk limits before taking any further action.
