You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
!!! note "We expire idempotency records after **an hour** (3600 seconds). After that, a transaction with the same payload [will not be considered idempotent](#expired-idempotency-records)."
306
+
307
+
You can change this expiration window with the **`expires_after_seconds`** parameter. There is no limit on how long this expiration window can be set to.
???+ important "Idempotency record expiration vs DynamoDB time-to-live (TTL)"
322
+
[DynamoDB TTL is a feature](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/howitworks-ttl.html){target="_blank"} to remove items after a certain period of time, it may occur within 48 hours of expiration.
323
+
324
+
We don't rely on DynamoDB or any persistence storage layer to determine whether a record is expired to avoid eventual inconsistency states.
325
+
326
+
Instead, Idempotency records saved in the storage layer contain timestamps that can be verified upon retrieval and double checked within Idempotency feature.
327
+
328
+
**Why?**
329
+
330
+
A record might still be valid (`COMPLETE`) when we retrieved, but in some rare cases it might expire a second later. A record could also be [cached in memory](#using-in-memory-cache). You might also want to have idempotent transactions that should expire in seconds.
331
+
303
332
### Lambda timeouts
304
333
305
334
???+ note
@@ -773,39 +802,6 @@ This is a locking mechanism for correctness. Since we don't know the result from
773
802
774
803
When enabled, the default is to cache a maximum of 256 records in each Lambda execution environment - You can change it with the **`local_cache_max_items`** parameter.
775
804
776
-
### Expiring idempotency records
777
-
778
-
!!! note "By default, we expire idempotency records after **an hour** (3600 seconds)."
779
-
780
-
In most cases, it is not desirable to store the idempotency records forever. Rather, you want to guarantee that the same payload won't be executed within a period of time.
781
-
782
-
You can change this window with the **`expires_after_seconds`** parameter:
This will mark any records older than 5 minutes as expired, and [your function will be executed as normal if it is invoked with a matching payload](#expired-idempotency-records).
797
-
798
-
???+ important "Idempotency record expiration vs DynamoDB time-to-live (TTL)"
799
-
[DynamoDB TTL is a feature](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/howitworks-ttl.html){target="_blank"} to remove items after a certain period of time, it may occur within 48 hours of expiration.
800
-
801
-
We don't rely on DynamoDB or any persistence storage layer to determine whether a record is expired to avoid eventual inconsistency states.
802
-
803
-
Instead, Idempotency records saved in the storage layer contain timestamps that can be verified upon retrieval and double checked within Idempotency feature.
804
-
805
-
**Why?**
806
-
807
-
A record might still be valid (`COMPLETE`) when we retrieved, but in some rare cases it might expire a second later. A record could also be [cached in memory](#using-in-memory-cache). You might also want to have idempotent transactions that should expire in seconds.
808
-
809
805
### Payload validation
810
806
811
807
???+ question "Question: What if your function is invoked with the same payload except some outer parameters have changed?"
0 commit comments