DynamoDB ClientRequestToken idempotency limits with conditional writes

DynamoDB ClientRequestToken idempotency limits with conditional writes

Goal is to prevent duplicate writes when AWS SDKs retry throttling or transient network errors for DynamoDB write operations. ClientRequestToken is intended to make PutItem, UpdateItem, DeleteItem and TransactWriteItems idempotent within an idempotency window.

Constraints include token scoping to AWS account and region, a default idempotency window of 10 minutes that can be extended up to 24 hours via IdempotencyWindow on supported operations, and that a single token applies to the entire TransactWriteItems transaction. Tokens may be reused across different tables after the window expires.

Uncertainty remains about how idempotency interacts with ConditionExpression on retries, whether in-flight deduplication returns consistent responses for partial transaction outcomes, and the practical reuse rules for tokens across tables after the window expires.

Is a ConditionalCheckFailedException returned on retry with the same ClientRequestToken treated as a duplicate of the original evaluation or as a new evaluation? Does in-flight deduplication guarantee identical response metadata for TransactWriteItems when items have mixed success and failure outcomes? Can the same token be safely reused across different tables within the same account and region after the idempotency window expires?