One of the places where the DynamoDB-API TTL feature differs from CQL's TTL is that when an item eventually expires, the expiration event is written to the DynamoDB Streams log, as explained in the DynamoDB documentation on TTL .
This is why the Alternator TTL feature uses real delete operations to expire items - as those get recorded in the Alternator Streams log.
However, there remain one missing piece in our implementation: According to the aforementioned documentation (and in practice), DynamoDB marks those expiration events with a special userIdentity flag saying that those deletes are "service" deletions, not regular user-initiated deletions. We are missing this flag in our Alternator Streams output.
We have an xfailing Alternator test, test_ttl.py::test_ttl_expiration_streams, which reproduces this incompatibility with DynamoDB.
One of the places where the DynamoDB-API TTL feature differs from CQL's TTL is that when an item eventually expires, the expiration event is written to the DynamoDB Streams log, as explained in the DynamoDB documentation on TTL .
This is why the Alternator TTL feature uses real delete operations to expire items - as those get recorded in the Alternator Streams log.
However, there remain one missing piece in our implementation: According to the aforementioned documentation (and in practice), DynamoDB marks those expiration events with a special
userIdentityflag saying that those deletes are "service" deletions, not regular user-initiated deletions. We are missing this flag in our Alternator Streams output.We have an xfailing Alternator test,
test_ttl.py::test_ttl_expiration_streams, which reproduces this incompatibility with DynamoDB.