AlgoVesta › Glossary › Retry logic

Order Execution

Retry logic

Retry logic is the set of rules that decides whether a failed request to an exchange or broker is sent again, how many times, after how long, and, most importantly, which requests must never be repeated because repeating them could place a second order.

Why it matters

Networks and venues fail in ways that look identical from the outside: a timeout can mean the order never arrived, or that it was accepted and the confirmation was lost. Retrying a read (balance, positions, order status) is harmless; retrying an order placement after an ambiguous failure can double the position, which is a worse outcome than missing one trade. Retries also interact with rate limits: a burst of retries during a venue incident can get an IP or key temporarily banned, taking every other account on that server down with it.

How AlgoVesta handles it

AlgoVesta distinguishes reads from writes. Read requests such as fetching positions are retried once after a short wait; order placements are not blindly retried after a timeout, because a lost confirmation is not proof that the order was lost. Instead the platform reconciles against the venue: the exchange's positions and trade history are checked, and an order that turns out to have been placed is recorded rather than duplicated. A duplicate guard rejects a second identical signal for the same account, symbol and direction within a short window, so a provider re-posting a message does not open two positions. When a venue returns a rate-limit or ban response, the affected key or server backs off instead of hammering the venue, and the condition is shown in the dashboard. Protective orders that fail to be created are retried and verified, and on forex accounts a position whose stop cannot be confirmed is closed by design. See idempotency and exchange rate limit.

Example

An order to buy 0.05 BTC times out after 10 seconds with no response. AlgoVesta does not resend it. It queries the account's open positions and recent fills, finds a new 0.05 BTC long that matches the order, records it with the exchange's fill price, and places the stop and target for it. Had the query found nothing, the signal would have been marked as failed with the timeout reason, and the trader could re-send it deliberately.

Common mistakes

In practice

See how AlgoVesta automates this