How can I retry a failed request without retrying every kind of error?

Separate the decision to retry from the code that reports or handles an error. First check whether the specific service describes this failure as transient. Microsoft’s Azure guidance gives HTTP 429 and 5xx responses as typical retry candidates, but says many 4xx responses usually point to a problem another attempt will not fix. That is guidance, not a universal rule for every API, so check the service’s own behavior. [S1]

Then ask whether repeating this particular operation is safe. A repeated request that creates, charges, or otherwise changes something may have a different effect from repeating a read. Guidance recommends considering idempotency because repeating a non-idempotent operation can cause inconsistencies. [S1]

A practical policy has three outcomes: retry, stop and report the failure, or stop and request review because the failure is not classified. This is safer than treating “an error occurred” as permission to repeat.

Here is a JavaScript-style sketch. isDocumentedTransient and isSafeToRepeat are deliberately placeholders: implement them from the service’s documentation and the operation’s behavior, not from a blanket rule. maxAttempts includes the first attempt.

async function requestWithRetry(send, options) {
  const {
    maxAttempts,
    isDocumentedTransient,
    isSafeToRepeat,
    delayForAttempt,
    deadlineReached
  } = options;

  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await send();
    } catch (error) {
      const mayRetry =
        attempt < maxAttempts &&
        isDocumentedTransient(error) &&
        isSafeToRepeat() &&
        !deadlineReached();

      if (!mayRetry) throw error;
      await delayForAttempt(attempt);
    }
  }
}

The stop conditions are visible: the attempt limit is reached, the failure is not known to be transient, repeating is not safe, or the deadline has been reached. In each case, the error is passed to the caller rather than retried. A real implementation must also make sure the delay itself fits within the remaining deadline; this sketch does not calculate that budget.

Use a bounded delay policy rather than retrying immediately in a tight loop. Azure-oriented API guidance recommends bounded retries with backoff and jitter, keeping attempts and delays within the request deadline, and limiting aggregate retries. It also suggests considering a circuit breaker when repeated dependency failures could exhaust capacity. [S2]

For example, a local policy might allow at most three total attempts, increase the wait after each failed attempt, add a small randomized variation, and refuse to wait past the caller’s deadline. Those numbers are illustrative placeholders, not universal settings. Choose values for your operation and dependency. If many calls are failing, a per-request attempt limit alone may still allow a large number of retries across the application; consider a shared limit or a circuit breaker as part of the broader design. [S2]

Keep the policy’s output observable in your application’s normal logs or metrics: record the attempt number and the final outcome using your existing conventions. Do not log sensitive request contents just to explain a retry.

Treat uncertainty as a reason to stop, not as a reason to retry. A status code or exception category is only useful if the specific service documents what it means for this operation. The cited guidance does not establish a universal classification for every API, nor does it determine whether your particular operation is safe to repeat. [S1] [S2]

Review these separately from the retry policy: authentication or input problems, failures with unknown meaning, operations whose repeated effects are unclear, and failures that may need user action. Route them through your ordinary error handling or a review path; do not silently turn them into repeated attempts.

Before enabling retries, test the decision logic with representative errors and confirm that each test stops or retries for the intended reason. That is a suggested review step, not evidence that the service will behave a particular way. Keep the policy configurable so you can adjust it if service guidance or the operation changes.