The retry is another decision

Software has a gentle word for doing something again: retry. The word suggests continuation. A request met resistance, paused, and resumed. Nothing important changed. The first attempt and the second belong to one operation, as naturally as a person repeating a sentence that was not heard the first time.

That picture is often useful. Networks fail briefly. Services become unavailable and return. A second attempt can turn an incidental interruption into an invisible recovery. Much of modern computing depends on this patience. But the word becomes dangerous when it travels from transport into judgment. A repeated transmission may carry the same bytes. A repeated decision does not necessarily carry the same meaning.

Between the first attempt and the second, time has passed. Data may have changed. Authority may have expired. Another actor may have completed the task. A limit may have been reached, a reservation released, a balance altered, or a person notified. Even when the request is identical, its circumstances are not. The retry is therefore not merely another delivery of the first decision. It is a new decision about whether the action remains warranted now.

The second attempt occurs in another world

Consider a system asked to transfer an amount, suspend an account, reserve an item, submit a filing, or send a consequential notice. The first attempt times out. The system cannot tell whether the action failed or whether only the confirmation failed. Retrying may complete an unfinished action. It may also duplicate a completed one.

This is the old difficulty of uncertainty at a boundary: one system knows what it asked for, another may know what it did, and the connection between them failed before either side could establish a shared account. The tempting response is to keep trying until success appears. But “success” can mean only that one attempt returned a satisfactory response. It does not prove that earlier attempts produced no effects.

The situation changes even when duplication is impossible. Suppose a review request fails because a downstream service is unavailable. Five minutes later, the evidence has been updated. The policy version has changed. The person’s authorization has been revoked. A second attempt now evaluates a different state under different conditions. Treating it as the same decision hides the fact that the basis for acting may have moved.

A retry repeats an instruction, not the world that made the instruction justified.

This does not make retries illegitimate. It makes them consequential. A careful retry can be safer than abandoning an operation halfway through. It can restore availability without asking a person to repeat work. But its safety comes from recognizing what it is: a fresh authorization to act under conditions that must be checked again.

A retry policy is a decision policy

Retries are usually described as operational settings: how many attempts, how long to wait, whether to increase the interval, and which errors count as temporary. Those settings look technical because they are written in configuration. In practice, they allocate risk.

A system that retries quickly favors completion over caution. A system that retries indefinitely treats eventual execution as more important than the possibility that the request has gone stale. A system that retries only certain failures embeds a theory about which failures preserve the original justification. None of those choices is neutral. Each determines when the system will act again without returning to the person or process that authorized the first action.

The right retry policy depends on the consequence. Fetching a public document can tolerate repetition that moving money cannot. Recomputing an internal summary is different from sending a denial letter. Repeating a reversible action is different from repeating one that changes someone’s standing. The policy must follow the action’s meaning, not merely the error code returned by the machinery beneath it.

Human review is not automatically the answer. Requiring a person after every timeout would turn routine interruptions into queues. The better distinction is between a retry whose preconditions can be established mechanically and one whose legitimacy depends on facts the system can no longer confirm. If the system can prove that no effect occurred, that authority remains active, and that the relevant state has not changed, another attempt may be ordinary recovery. If it cannot, escalation is not a failure of automation. It is an admission that the system no longer knows enough to act safely.

Record the attempts, not only the outcome

Most records flatten retries. They show that an operation ultimately succeeded or failed, perhaps with a count of attempts. The intermediate uncertainty disappears. That creates a clean story at the cost of the very information a later reviewer will need.

An adequate account should preserve each attempt as an event: when it occurred, what state it relied on, what authority remained active, what response returned, and what the system knew before deciding to try again. It should distinguish “the action failed” from “confirmation was not received.” It should record whether the system checked for prior effects and whether any relevant condition changed between attempts.

This matters even when the final outcome is correct. A successful transfer can still have been retried recklessly. A correctly delivered notice can still reveal a policy that would have sent it twice under slightly different conditions. The quality of the outcome does not settle the quality of the process that produced it.

A Decision Receipt for a retried action should therefore describe a small sequence of decisions, not one action with incidental noise around it. The first attempt had a basis. The uncertainty that followed created a new state. The retry policy evaluated that state and authorized another act. If there was a third attempt, the same logic applied again.

Once retries are seen this way, design improves. Limits become tied to consequence. Authority is checked at each attempt. Idempotence becomes more than an implementation convenience; it becomes protection against uncertain history. Logs stop celebrating eventual success and begin preserving the path by which the system reached it.

The retry is not evidence that the original decision persisted unchanged. It is evidence that the system decided again. We should build and record it with the seriousness that second decision deserves.

— Dispatches · Summit Cognitive