How a Trading Agent Can Retry Orders Safely Without Duplicating Trades
Learn practical techniques for building a retry loop that avoids duplicate orders, handles timeouts, reconciles execution reports, and keeps owner signed risk
Produced with automation, then checked by deterministic quality rules and an independent source-grounded review before publication.
- 01Use a durable, unique identifier for each order request.
- 02Persist order state before sending to the venue to survive crashes.
- 03Treat timeouts as ambiguous outcomes and reconcile after execution.
- 04Apply explicit error handling and back‑off to reduce repeated failures.
- 05Integrate owner‑signed limits to bound exposure even during retries.
A trading agent can retry an order safely by assigning a durable identifier, persisting intent before transmission, and reconciling the result after any timeout. This approach prevents duplicate fills while keeping risk limits intact and respects the authoritative market and account interfaces.
Why Does a Simple Retry Lead to Duplicate Orders?
When an agent sends an order and does not receive a confirmation-perhaps due to a network glitch or venue latency-it may assume the order failed and resend it. If the original order actually succeeded, the second submission creates a duplicate. Because market venues treat each submission as a new instruction, the agent can unintentionally double its exposure and breach owner‑signed limits.
What Is Idempotence and How Does It Apply to Order Submission?
Idempotence means that repeating the same operation yields the same result without side effects. For trading, this is achieved by attaching a unique, durable order ID that the venue recognises across retries. If the venue receives the same ID again, it can safely ignore the duplicate or return the original execution report, ensuring that limits are not consumed twice.
- The order ID must be generated before any network call.
- It should be stored in durable storage that survives process restarts.
- The venue must support idempotent order keys (most modern APIs do).
How Should an Agent Persist Order State?
Persisting state ensures that a crash or restart does not lose the knowledge that an order was already sent. A simple key‑value store or a transactional database can hold the order ID, parameters, and a status flag such as pending, confirmed, or failed. This record becomes the single source of truth for any later decision.
- 01Generate the order ID and write a record with status “pending”.
- 02Send the order to the venue using the same ID.
- 03On receipt of a confirmation, update the record to “confirmed”.
- 04If a timeout occurs, read the record and treat the outcome as ambiguous.
When Is It Safe to Retry After a Timeout?
A timeout does not prove failure; it only indicates that the agent did not get a response in time. Before retrying, the agent should query the venue for the order status using the durable ID. If the venue reports no execution, the agent may safely resend. If the status is unknown, a conservative approach is to pause, alert the owner, and await manual review.
Treat every timeout as an ambiguous state and verify before taking further action.
How Do Risk Controls Remain Effective During Retries?
Owner‑signed limits-such as maximum order size, daily notional, or loss caps-apply to each distinct order request. Because an idempotent retry does not create a new logical order, the limits are not consumed a second time. If the venue does not support idempotence, the agent must enforce its own guardrails by checking the persisted status before counting the order against limits again.
What Are Common Pitfalls and How to Mitigate Them?
- Missing durable storage: Use a reliable database rather than in‑memory caches.
- Assuming immediate confirmation: Implement exponential back‑off and multiple status checks.
- Ignoring venue warnings: Respect data freshness and source warnings in market data.
- Relying on a single retry: Design a configurable retry limit and escalation path.
Frequently asked questions
Query the venue using the same durable order ID. If the venue returns a fill report, treat the order as completed; otherwise, consider it unfilled.
Maintain a local guard that checks the persisted status before counting the order against risk limits, and limit retries to a single additional attempt after manual review.
The principles of durable identifiers, persisted state, and status reconciliation apply across stocks, crypto, futures, options, and prediction markets, but each venue may have specific API nuances that must be respected.
A pause after a configurable number of consecutive failures-such as three-allows the system to back‑off, alert the owner, and avoid cascading issues. See the article on [When Should an AI Trading Agent Pause After Repeated Errors?](/blog/ai-trading-agent-pause-after-errors) for guidance.
The guide [How to run an AI trading agent with real‑money controls](/blog/run-ai-trading-agent-safely) provides a broader view of limits, emergency stops, and owner‑authority separation.
Reconciliation confirms that the agent’s internal state matches the venue’s records, preventing deviation that could cause duplicate exposure. For a deeper dive, read [Why Positions Must Be Reconciled After Every Agent Order](/blog/reconcile-agent-positions).
Sources and verification
Product claims in this article were checked against these first-party references. Runtime status remains authoritative for current availability.
- Felix documentationfirst party
- Felix machine referencefirst party
Build with Felix now.
Felix infrastructure is live through MCP and the API. The full trading app launches September 17.
Repeated execution errors can signal deeper problems. This guide explains when to pause an AI trading agent, how to use owner‑authorized limits, and what operational safeguards to apply.
The bid‑ask spread is a key market signal that tells a trading agent about liquidity, price efficiency, and execution risk. This article explains its meaning, practical uses, and the uncertainties involved.