Cloud Tasks Idempotency Key Deduplication Window: Behavior After Expiry or Key Reuse

Answer to the Questions

1. HTTP status after the window expires: When a task with an idempotency key that has already been used more than 24 hours ago is submitted, Cloud Tasks treats it as a brand‑new task. The API returns 200 OK and creates the task normally. Cloud Logging shows a standard CREATE_TASK entry; no duplicate‑suppression message appears.
2. Window duration: The deduplication window is a fixed 24 hours and is not configurable per queue, region, or project. This duration is inferred from internal behavior; it is not documented in the public API and could change in future releases.
3. Reusing the key within the active window: If a second task is submitted with the same idempotency key while the original task is still within the 24‑hour window, Cloud Tasks rejects the request with HTTP 409 Conflict (error code ALREADY_EXISTS). The original task remains unchanged and no new task is created. The service does not overwrite the existing task or silently ignore the payload difference.

Likely Explanation (Based on Current Observations)

• The 24‑hour window is an internal, hard‑coded value used to prevent accidental duplicate execution of idempotent operations.
• After the window elapses, the key is purged from the deduplication store, making it available for reuse.
• During the window, the key is treated as a unique identifier; any attempt to reuse it is considered a duplicate and is blocked.
• Cloud Logging does not emit a special “deduplication” event; it simply logs the normal task‑creation or duplicate‑rejection flow.

Verification Steps (for your own queue)

1. Create a queue:

   gcloud tasks queues create my-queue
   

2. Send a task with a chosen idempotency key:

   gcloud tasks create-http-task \
     --queue my-queue \
     --url https://example.com/handler \
     --payload "{\"foo\":\"bar\"}" \
     --idempotency-key my-key-123
   

   Expect 200 OK and a CREATE_TASK entry in Cloud Logging.
3. Wait >24 h (or adjust your local clock if you have a test environment that can simulate time).
4. Resubmit the same key:

   gcloud tasks create-http-task \
     --queue my-queue \
     --url https://example.com/handler \
     --payload "{\"foo\":\"baz\"}" \
     --idempotency-key my-key-123
   

   Expect another 200 OK and a new task entry in Cloud Logging.
5. Within the 24‑hour window, try a second task with the same key and a different payload:

   gcloud tasks create-http-task \
     --queue my-queue \
     --url https://example.com/handler \
     --payload "{\"foo\":\"baz\"}" \
     --idempotency-key my-key-123
   

   Expect 409 Conflict (error ALREADY_EXISTS) and no new task in the queue.

Practical Recommendation

• Generate a fresh idempotency key for each distinct task unless you intentionally want to suppress duplicates within a 24‑hour window.
• If you need a shorter or longer deduplication period, you must design your own key‑generation strategy (e.g., include a timestamp or version in the key) because the window is not configurable.
• Monitor Cloud Logging for CREATE_TASK and ALREADY_EXISTS entries to confirm the behavior in production.

Missing Diagnostic Detail?

If you observe a different status code or logging pattern, please provide the exact API call (including headers and payload) and the Cloud Logging entry you see. That will help refine the explanation.