The dangerous moment comes after success

Consider this sequence:

1. Client sends operation_id=op_7f3
2. Editor applies the change at revision 184
3. Service persists the successful result
4. Connection drops before the client acknowledges it
5. Client reconnects and asks about operation_id=op_7f3

At step five, blindly retrying the mutation can duplicate an object, overwrite a newer file, or spend credits twice. Simply refusing to retry does not solve it. The user may never see the successful result, and stale delivery state can block later changes.

HTTP supplies part of the vocabulary. RFC 9110 defines an idempotent request method as one whose intended effect is the same whether the request is sent once or several times. An AI editor action is often a compound, stateful mutation, though. “Add a light beside the door” is not naturally equivalent to PUT on a known resource.

The safer pattern is to keep the operation identity stable, record its terminal result, and replay that result instead of replaying the mutation. Request semantics alone cannot recover an outcome that was never shown to the client.

A receipt is not an acknowledgement

An acknowledgement says one side received a message. A durable receipt says the system accepted a specific operation and knows how it ended. Those facts need different lifetimes.

The AWS Builders' Library guidance on idempotent APIs recommends a unique client request identifier, allowing repeated calls to return a semantically equivalent response instead of repeating the work. The same idea fits AI editors, coding agents, and background tool calls.

A practical receipt might look like this:

{
  "operation_id": "op_7f3",
  "intent_hash": "sha256:...",
  "status": "applied",
  "base_revision": 183,
  "result_revision": 184,
  "result_ref": "results/op_7f3",
  "delivery_state": "pending"
}

This is a design example, not a description of Summer Engine's internal schema. What matters is the split between the operation's terminal state and its delivery state. The mutation can be complete while delivery is still pending. On reconnect, the client asks for the recorded result. It does not create another edit.

This also sharpens a phrase that is often used too loosely: exactly once. A network cannot ensure that a reply is observed exactly once. In practice, a system aims for an exactly-once effect through a stable operation identifier, idempotent handling, durable terminal state, and replayable delivery. The acknowledgement might be sent more than once. The edit should still land once.

Expiration must release the queue

Receipts and acknowledgements cannot live forever. A long editor session can collect reconnects, abandoned pages, and clients that never send the final acknowledgement. If every missing acknowledgement permanently occupies a delivery slot or mutation lock, the recovery mechanism eventually creates its own outage.

Summer Engine's notes address both sides of the lifecycle. Results remain recoverable after reloads, while expired acknowledgement entries are retired so they cannot permanently block later mutations. Delivery also remains bounded during long sessions. The useful goal is controlled recovery, not unlimited retention.

A sound policy separates three clocks:

1. Keep the operation record long enough to cover realistic reload and reconnect windows.
2. Give delivery attempts a strict retry budget and backoff policy.
3. Let an expired acknowledgement release queue and lock state without immediately erasing the audit trail.

If the terminal result has already aged out, the client should reconcile with current project state before it offers another mutation. It should not guess silently. Expiration policy belongs in the failure tests because a system can recover correctly today and still jam after weeks of abandoned acknowledgements.

Test the uncertain window

Teams building agent tools can test the failure window with one mutation and a forced disconnect at every boundary:

1. Disconnect before the server accepts the operation. A retry may start new work.
2. Disconnect after acceptance but before execution. The same operation ID should attach to the pending work.
3. Disconnect after the mutation commits but before result delivery. Reconnect should replay the result, not the mutation.
4. Reload after delivery but before acknowledgement. The duplicate result should be harmless and recognizable.
5. Never acknowledge the result. Later independent mutations should eventually proceed.
6. Reconnect repeatedly during a long session. Memory, queue length, and retry traffic should remain bounded.

These checks also belong in webhook workers and API integrations. Our guide to verifying, enqueueing, and reconciling background webhooks covers the server-side version. For agent-facing APIs, reviewable tool results help show users what actually changed.

Put recovery in the interface

A useful recovery path is more than a database row. The editor should tell the user that an earlier operation completed, identify the revision or changed assets, and mark a replayed result as distinct from a newly executed action. That makes an uncertain outcome less likely to trigger an unsafe manual retry.

Summer Engine's release is specific to an AI game editor. The same failure window appears in coding agents, design tools, browser automations, and assistants that call mutating APIs. Any of them can finish work just before a tab reloads or a socket disappears.

In that moment, “try again” is not a recovery strategy. The product needs an identity for the original intent, durable evidence of the outcome, and a delivery path that can resume without repeating the effect. Summer Engine's release treats result delivery as product state, not temporary interface plumbing. That is the detail worth copying.