Fluxos DynamoDB: TrimmedDataAccessException

TL;DR — DynamoDB Streams mantém registros por 24 horas; os registros mais antigos são cortados e desaparecem do fluxo. Essa exceção significa que você solicitou uma posição que foi reduzida – um ponto de verificação com mais de um dia, geralmente de um consumidor que estava em baixa ou ficou para trás. Você não pode recuperar esses registros do fluxo: retome a partir de TRIM_HORIZON (registro sobrevivente mais antigo) e reconcilie a lacuna da própria tabela.

O que significa

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

Ao contrário de um iterador expirado - onde apenas seu identificador de posição ficou obsoleto - os dados cortados são genuinamente removidos. Solicitar um iterador de fragmento em um SequenceNumber aparado ou ler um fragmento cujos registros envelheceram gera isso. O fluxo é um buffer contínuo de 24 horas, não um arquivo.

Por que isso acontece

O consumidor ficou inativo por mais de 24 horas — uma interrupção, um trabalhador pausado, um gatilho desativado esquecido — e seu ponto de verificação agora aponta para um território aparado.
O atraso de processamento excedeu a retenção — o consumidor funciona, mas é mais lento que a taxa de gravação e fica mais de um dia atrasado.
Um ponto de verificação armazenado obsoleto – a reinicialização de um consumidor antigo com um SequenceNumber persistiu semanas atrás.
Ler um fragmento antigo de ponta a ponta — percorrendo a linhagem de fragmentos de um fluxo de longa duração e solicitando intervalos anteriores à retenção.

Como corrigir

Retome a partir do registro mais antigo disponível e aceite a lacuna:

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

Use LATEST se só a atividade nova importa.

Reconcilie a janela perdida a partir da fonte da verdade — a tabela ainda tem o estado atual de todo item. Um Scan/Query limitado sobre as chaves afetadas (ou uma exportação para tabelas grandes) reconstrói o que os registros cortados teriam te dito, menos as versões intermediárias.
Alerte sobre o atraso do consumidor — monitore a idade dos registros que você está processando (ou a métrica IteratorAge do Lambda) e acione muito antes de se aproximar de 24 horas.
Precisa de retenção mais longa? Faça stream para um buffer durável conforme os registros chegam (por exemplo, Kinesis Data Streams via padrões de Kinesis adapter, ou persista os registros processados você mesmo) — o próprio DynamoDB Streams não pode ser estendido além de 24 horas.
Reinicie o checkpoint após a recuperação. Persista o novo SequenceNumber obtido a partir de TRIM_HORIZON para que o consumidor não retome a antiga posição cortada ao reiniciar.

No DynoTable

Depois de uma lacuna de corte, reconcilie o estado atual dos itens a partir da tabela — abra-a com ⌘K e navegue ou filtre as chaves que seu consumidor perdeu. O DynoTable mostra os dados ao vivo da tabela, independentemente da janela de 24 horas do stream.

Dimensione a leitura de recuperação com a calculadora de preços. Copie o LatestStreamArn da tabela no painel de metadados antes de reiniciar o consumidor. Troque de perfil com ⌘P; veja Connect to AWS e Install.

Fontes

GetRecords — Amazon DynamoDB Streams API Reference (verificado em 2026-07-13)
Change data capture for DynamoDB Streams (verificado em 2026-07-13)

Erros relacionados

ExpiredIteratorException — o primo recuperável: posição obsoleta, dados ainda lá.
Stream não habilitado
StreamArn inválido
Aprenda: DynamoDB Streams

Referências

Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima.