DynamoDB Streams : TrimmedDataAccessException

TL;DR — DynamoDB Streams conserve les enregistrements pendant 24 heures ; les enregistrements plus anciens sont purgés et disparaissent du stream. Cette exception signifie que tu as demandé une position qui a été purgée — un point de contrôle vieux de plus d'un jour, en général celui d'un consommateur qui était arrêté ou avait pris du retard. Tu ne peux pas récupérer ces enregistrements depuis le stream : reprends à partir de TRIM_HORIZON (l'enregistrement survivant le plus ancien) et comble le trou depuis la table elle-même.

Ce que ça signifie

TrimmedDataAccessException: The data you are trying to access has been trimmed.

Contrairement à un itérateur expiré — où seule ta référence de position est devenue périmée — les données purgées sont réellement supprimées. Demander un itérateur de shard à un SequenceNumber purgé, ou lire un shard dont les enregistrements ont dépassé leur durée de rétention, déclenche cette erreur. Le stream est un tampon glissant de 24 heures, pas une archive.

Pourquoi ça arrive

Le consommateur a été arrêté plus de 24 heures — une panne, un worker en pause, un déclencheur désactivé et oublié — et son point de contrôle pointe désormais vers une zone purgée.
Le retard de traitement a dépassé la rétention — le consommateur tourne, mais plus lentement que le débit d'écriture, et a dérivé de plus d'un jour.
Un point de contrôle stocké périmé — redémarrer un ancien consommateur avec un SequenceNumber persisté il y a des semaines.
Lecture d'un ancien shard de bout en bout — parcourir la lignée de shards d'un stream de longue durée et demander des plages antérieures à la rétention.

Comment le corriger

Reprends à partir de l'enregistrement disponible le plus ancien et accepte le trou :

const {ShardIterator} = await streams.send(
  new GetShardIteratorCommand({
    StreamArn: streamArn,
    ShardId: shardId,
    ShardIteratorType: 'TRIM_HORIZON' // oldest untrimmed record
  })
);

Utilise plutôt LATEST si seule l'activité récente compte.

Comble la fenêtre manquée depuis la source de vérité — la table contient toujours l'état actuel de chaque élément. Un Scan/Query borné sur les clés concernées (ou un export pour les grandes tables) reconstruit ce que les enregistrements purgés t'auraient appris, aux versions intermédiaires près.
Alerte sur le retard du consommateur — surveille l'âge des enregistrements que tu traites (ou la métrique IteratorAge de Lambda) et alerte bien avant d'approcher les 24 heures.
Besoin d'une rétention plus longue ? Envoie le stream dans un tampon durable au fur et à mesure que les enregistrements arrivent (par exemple Kinesis Data Streams via les patterns de l'adaptateur Kinesis, ou persiste toi-même les enregistrements traités) — DynamoDB Streams lui-même ne peut pas dépasser 24 heures.

Reconstruire l'état après un trou revient à regarder ce qui est réellement dans la table maintenant — l'application de bureau DynoTable transforme cette passe de réconciliation en une requête navigable plutôt qu'en un script. Tu dimensionnes la lecture de rattrapage ? Le calculateur de tarifs DynamoDB estime le coût en RCU.

Erreurs liées

ExpiredIteratorException — le cousin récupérable : position périmée, données toujours présentes.
Stream not enabled
Invalid StreamArn
En savoir plus : DynamoDB Streams

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.