Retry logic is the automation design pattern that responds to a failed operation by re-attempting it automatically — a defined number of times, with a defined interval between attempts — before concluding that the failure is permanent and escalating to the exception handler. It is the mechanism by which automation distinguishes between transient failures (a network timeout, a momentary application unavailability, a resource contention error that resolves in seconds) and permanent failures (an invalid vendor code, a duplicate transaction key, an API validation error on the submitted data). Transient failures are candidates for retry; permanent failures are not, because retrying a permanent failure wastes processing time, delays error notification, and may cause unintended side effects.
How It Works
Retry logic operates through three configurable parameters: the retry count (the maximum number of additional attempts after the initial failure), the retry interval (the wait time between attempts — fixed, linear increase, or exponential backoff), and the retry condition (which specific failure types trigger a retry versus which are treated as permanent). The retry condition is the most important parameter: without it, retry logic applies uniformly to all failures, including permanent ones.
Exponential backoff — where the interval between retries doubles with each attempt (1 second, 2 seconds, 4 seconds, 8 seconds) — is the recommended retry interval strategy for API integrations subject to rate limiting. When a 429 Too Many Requests response is received, exponential backoff reduces the request frequency progressively, giving the target system time to recover from the rate limit breach before the next attempt. Fixed-interval retry is appropriate for application availability failures where the recovery time is not proportional to the number of prior retries.
Design Considerations
Retry logic in financial transaction automation requires a specific additional design consideration: idempotency. If a payment posting operation sends an HTTP POST to the ERP, the response network times out before the bot receives it, and the bot retries the POST, the ERP may have received and processed the first POST before the timeout — resulting in a duplicate payment posting on the retry. Retry logic for financial transaction writes must check for idempotency: does the target system support idempotency keys (a unique transaction reference that prevents duplicate processing), and if not, does the retry logic include a pre-retry check for existing transaction records that would indicate the prior attempt succeeded?
What Breaks in Production
The specific failure that produces duplicate financial transactions from retry logic is a retry sequence that does not check for prior processing before re-attempting a write operation. An automation posting a journal entry to Oracle EBS receives a timeout on the first attempt. The retry logic re-submits the journal entry. The ERP processes the second submission, creating a duplicate journal. The first submission, which also succeeded, is discovered during reconciliation. Two identical journal entries exist in the GL for the same transaction. The reconciliation team must identify and reverse the duplicate — a manual correction process that the retry logic was supposed to make unnecessary. Idempotency checking before retry, using the transaction’s unique reference in a prior-existence query, prevents this class of duplicate.
How Loop Wise Solutions Designs for This
Retry logic design is a mandatory section of every automation design document we produce. We specify the retry count, interval strategy, and condition for each operation that involves external system calls — distinguishing API calls, database operations, and file operations, which have different failure mode profiles. For financial write operations, we design an explicit idempotency check as part of the retry sequence, and we include the duplicate detection approach as a test case in the automation testing framework.
