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

Goal

Understand the exact behavior of Cloud Tasks when an idempotency key is presented after the service's deduplication window has expired, or when the same key is intentionally reused for a logically distinct task payload.

Constraints and Uncertainty

Cloud Tasks documents an optional idempotency_key header that suppresses duplicate execution within a deduplication window. The documentation does not specify the window's duration, nor does it clarify whether the service returns a distinct response code, logs a detectable event, or silently discards the second task when the key is reused after the window closes. Additionally, reusing a key for different work is cautioned against, but the observable outcome — whether the second task is dropped, queued, or fails — is not explicitly defined in the public API reference.

Questions

1. What HTTP status code or Cloud Logging entry does Cloud Tasks emit when a task with a previously used idempotency key is submitted after the deduplication window has elapsed?
2. Is the deduplication window duration documented, configurable, or fixed per queue/region?
3. If a key is reused for a different payload within the active window, does the service reject the new task, overwrite the original, or silently ignore the payload difference?