Make a Small Automation Retry Without Duplicating the Work

AI-assisted practical guide. Examples are hypothetical; proposed workflows are editorial suggestions.

A retry should repeat unfinished work without duplicating completed effects. Design the workflow around a stable job identity and an inspectable completion record before adding automatic retry behavior.

Define what counts as the same job

Use a stable reference for the intended operation and distinguish it from an individual attempt. Record the input version, destination, attempt time, and observed outcome. A timeout may mean the result is unknown, not that nothing happened.

Before retrying an operation with external effects, check whether the destination already reflects the intended change. The exact mechanism depends on the service and needs appropriate implementation review.

Walk through a hypothetical upload

Imagine a document upload request times out after transmission. Retrying immediately under a new identity could create a second document. A better design investigates the existing operation or destination before deciding whether another attempt is necessary.

Keep uncertain outcomes visible. Do not mark them failed solely because the client did not receive a response.

Test the recovery path

In a low-impact test environment, examine interruption before the action, during the request, and after the destination changes. Verify the actual result each time. This article describes a design principle, not tested production code. A useful retry plan includes bounds, logging, and manual recovery so repeated attempts cannot continue indefinitely without anyone understanding their effects.

Related guides

• Record an Automation Failure So Someone Can Reproduce It
• Separate an AI Suggestion from an Approved Action