Prevent duplicate actions after an AI timeout

A timeout tells you that your workflow did not receive a result in time. It does not tell you whether the external service performed the action. That distinction matters when an AI workflow sends a message, creates a booking, or changes a customer record.

The safest response begins by preserving the identity of the original action and checking what happened. Starting a fresh action can produce a duplicate. This guide helps an operator and implementer agree on the states, evidence, and retry rules they need before enabling writes.

Recognize the uncertain outcome

Imagine that a workflow submits an approved appointment confirmation. The provider accepts it, but the response is lost before the workflow records success. The screen displays an error. If the next step simply sends again, the customer may receive two confirmations.

Other sequences produce the same visible error: the provider may have rejected the request, or the connection may have failed before submission. The interface should therefore distinguish a confirmed failure from an unknown result. Labeling every timeout Failed invites operators to repeat actions that might already be complete.

The HTTP specification advises against automatically retrying non-idempotent requests unless the client knows the semantics make the retry safe or can determine that the original was not applied. RFC 9110 retry semantics.

Give the business action a durable identity

Assign an operation identifier before the first external attempt. Keep it with the reviewed payload, destination, connector, and approval reference. Record each network attempt separately under that same operation.

A customer's request to send one confirmation should remain one operation even if a worker restarts or the browser is reopened. Repeated clicking should retrieve that operation's status rather than create another one. A genuinely different approved message should get a new identity.

Have the implementer explain how concurrent workers claim an operation and how a completed result is recognized. A unique database record can help coordinate local work, but it cannot by itself guarantee that an external service performs an action only once. There is still a boundary between the local record and the remote effect.

Expect duplicate background delivery

Background queues are another source of repetition. Cloudflare Queues documents at-least-once delivery by default, which means a message can arrive more than once. Its guidance recommends unique identifiers and deduplication for processing that would otherwise produce unintended effects. Queue delivery guarantees.

Apply that behavior to the workflow design. A second delivery of the same queued operation should look up existing state. It should not assume that receiving a message proves new business intent. Keep the operation identifier when moving work into a recovery queue, and preserve it during a controlled replay.

Never place raw credentials or unnecessary customer information inside the identifier. Use an opaque value and store any required business association in an access-controlled record.

Check the provider's idempotency contract

Idempotency means a repeated operation has the same intended effect as one operation. Some APIs support a key that lets the provider recognize retries. Support is specific to the provider, endpoint, and sometimes API version.

Stripe's API v1 documentation, for example, says retries with a retained key return the saved status and body, including server errors. It also says keys may be removed after they are at least 24 hours old; reusing a removed key can create a new request. Current API v2 retry behavior differs. Stripe idempotency documentation.

This is an illustration of details to verify, not a recommendation to connect payments to a beginner workflow. For your connector, record key support, retention, parameter matching, concurrency behavior, and how outcomes are queried. Reuse the same key only for the same intended operation with the required unchanged parameters and within the documented conditions.

Use a three-way timeout decision

Write an operator procedure with three branches:

1. Confirmed completed: record the provider's receipt and do not execute again.
2. Confirmed not applied: retry only under current permission, approval, and provider rules.
3. Still uncertain: hold the operation and investigate without creating a fresh external action.

A provider lookup by an operation reference or returned resource identifier is stronger evidence than a general search that happens to find nothing. Search results may lag, and two legitimate actions can have similar text. Define which evidence your particular connector considers authoritative.

If the service offers neither reliable idempotency nor a way to establish the result, manual review may be necessary. Tell the operator exactly what remains unknown. Waiting longer alone does not prove that the first attempt failed.

A fictional recovery drill

Birch Sample Services is a fictional maintenance office testing appointment notices. In a controlled test, the provider accepts a notice and the connection is interrupted before its receipt is saved. A second queue delivery then arrives.

The expected behavior is to recognize the existing operation, keep it in an uncertain state, and use the provider's supported reconciliation route. Once the test receipt is found, the operation becomes completed. No second notice is created. A separate test disconnects the provider before any request is applied and checks the documented safe-retry path.

These are acceptance scenarios, not measured customer results. Test them with invented appointments and a provider sandbox or controlled destination.

Include permission changes in recovery

Access can be removed while an operation is waiting. An old approval, a queued message, or a previously valid credential should not override the current stop decision. Check authorization again before any permitted retry, and record when recovery is blocked by revocation.

Finish the runbook with a responsible person, an escalation path, and a clear explanation of completed versus accepted outcomes. Review uncertain operations deliberately rather than hiding them in an endless retry loop.

Bring one timeout scenario and your connector's retry documentation to InstallAI when discussing an action-enabled workflow. Resolving this behavior early is easier than explaining duplicate messages or records later.