A crash or timeout does not mean a task-creation request failed. The server may have created the landing task, while the caller lost the response before recording success. If recovery sends the same POST again, an endpoint without deduplication may create a second task.
Prevent this by assigning one stable identity to the logical task, reusing it on every retry, and having the receiving service atomically recognize repeats as the original operation. The title does not identify a particular landing-task API, so its support for idempotency keys and its key-retention rules must be checked in that service’s documentation.
How a retry creates a duplicate
The failure happens in the gap between a side effect and confirmation of that side effect:
- A worker sends a POST asking the service to create a landing task.
- The service creates the task.
- The worker crashes, times out, or loses the response before saving that the request succeeded.
- Recovery cannot tell whether the first attempt took effect, so it sends the POST again.
- If the receiver treats the second request as new, it creates another task.
The caller’s uncertainty is the important part: a missing response is not proof that the server did nothing. AWS describes this general challenge in its Well-Architected guidance on idempotent operations. It notes that exactly-once effects are harder than either making one request or retrying until confirmation.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What idempotency changes
An operation is idempotent when repeating it has the same effect as performing it once. For task creation, the receiver needs a way to recognize that two requests refer to one logical task, rather than two separate tasks.
Give that logical operation a stable idempotency key or client token. The first request associates the key with the created task; a repeated request with the same key should return or identify that original outcome instead of creating a new task. AWS recommends idempotency tokens and tracking their state, with suitable consistency and atomicity controls, in its reliability guidance.
How to make task creation safe to retry
- Create a durable operation identity. Mint or derive one key for the logical landing task and persist it before retryable work begins. If a workflow engine can replay a step, ensure the key survives replay or is derived deterministically; generating a fresh key during each replay defeats deduplication. See AWS Durable Execution guidance on idempotency.
- Send the same key on every attempt. Use the API’s documented idempotency header or client-token field, including its required format and scope. Never generate a replacement key merely because a request timed out.
- Deduplicate at the receiver. Persist the key with the task state, and make claiming the key and creating or retrieving the task atomic under concurrent requests. A transaction, uniqueness constraint, or equivalent coordination can help, depending on the storage system. A check-then-create sequence without concurrency control can let two simultaneous retries both create tasks.
- Define the repeat response. On a recognized key, return the original task or result, or provide a duplicate outcome the caller handles as success. A duplicate response is not, by itself, evidence that the initial operation failed.
- Propagate identity across side effects. If task creation triggers another service or action, pass along a stable identity or use that downstream service’s own deduplication contract. Idempotency at the first API boundary cannot prevent a downstream system from repeating an unprotected side effect.
- Test the lost-confirmation window. Arrange for the server to create the task, then drop the response or crash the caller before it records completion. Replay with the same key and verify that only one task exists and that the caller can recover its result.
Choose the right deduplication boundary
There are two common approaches. A receiver-supported key uses the API’s own idempotency contract. Application-managed deduplication stores operation keys and task state in the receiving application. Neither approach is sufficient unless retries are coordinated atomically and any later side effects are covered.
| Design concern | Receiver-supported idempotency | Application-managed deduplication |
|---|---|---|
| Key handling | Follow the API’s documented header or token, scope, parameter matching, and expiry. | Define and persist a stable operation key alongside task state. |
| Concurrent retries | Confirm the service coordinates simultaneous requests for the same key. | Use a transaction, uniqueness constraint, or equivalent concurrency control. |
| Repeat response | Check whether the API returns the original result or another documented duplicate response. | Implement a response that retrieves or identifies the existing task. |
| Downstream effects | Do not assume the key covers systems beyond the API’s documented boundary. | Propagate identity or deduplicate separately at each side-effecting boundary. |
| Key lifetime | Use the documented retention period; it is API-specific. | Set retention to cover the relevant replay and recovery window, and account for cleanup. |
Why retry modes alone do not guarantee one task
A queue or workflow’s delivery and retry behavior does not automatically make the destination’s side effects occur once. Amazon SQS standard queues can deliver a message again in rare conditions, and AWS advises designing applications to tolerate repeated processing in its standard-queue delivery documentation. That is a general duplicate-processing example, not evidence that a queue is involved in this landing-task failure.
Free tools Windows power users keep installed
One-click scans. No signup required.
AWS Durable Execution guidance also distinguishes at-most-once behavior per retry attempt from a single execution across a workflow: its documentation says, “Neither guarantees the step runs exactly once across the entire workflow,” when retries remain enabled. For an external service that supports idempotency, use a stable key across those attempts rather than relying on retry mode alone. See the Durable Execution idempotency guidance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Check the API’s exact key contract
Key behavior differs by service, so verify the current API documentation before relying on it. For example, Stripe documents that it saves the first status code and response body for a key, checks that later requests use matching parameters, and may remove keys once they are at least 24 hours old. Those are Stripe-specific rules, not a universal retention period or behavior for an unnamed landing-task endpoint. See Stripe’s idempotent request documentation.
Rank #4
AWS ECS RunTask is another product-specific example: its API supports client-token idempotency, as described in the RunTask API reference. This does not establish that the landing-task service in this scenario is ECS or has the same token rules.
Quick Recap
Best Value
- Confirm the key’s required field or header, format, and scope.
- Check whether the service validates that repeated requests have matching parameters.
- Find out how long keys are retained and what happens after expiry.
- Determine what response a repeated key produces and whether concurrent requests are safely coordinated.
- Check whether the key covers downstream effects or only the initial API operation.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
