Muitas ações em uma chamada TransactWriteItems

TL;DR — Uma transação DynamoDB é limitada a 100 ações. TransactWriteItems (e TransactGetItems) rejeita uma solicitação com mais de 100 ações Put/Update/Delete/ConditionCheck. Divida o trabalho em múltiplas transações — ou, se você não precisar de atomicidade do tipo tudo ou nada, use BatchWriteItem (25 por chamada).

O que significa

ValidationException: 1 validation error detected: Value '<your request>' at 'transactItems' failed to satisfy constraint: Member must have length less than or equal to 100

O serviço ecoa toda a sua solicitação serializada onde o <your request> está localizado – para uma transação de 101 ações com aproximadamente 65.000 caracteres. A conclusão é a última frase.

O TransactWriteItems agrupa ações que são todas confirmadas ou revertidas juntas, mas uma única transação pode conter no máximo 100 ações, e o tamanho agregado dos itens na transação não pode exceder 4 MB. Passe mais e o DynamoDB rejeita toda a chamada antes de executar. A mensagem geralmente é lida como uma restrição no comprimento da lista TransactItems. É um HTTP 400 ValidationException, do lado do cliente e não pode ser repetido até que a transação seja menor.

Por que isso acontece

  • Agrupando muitas escritas atomicamente — tentando confirmar 150 colocações em uma transação.
  • Um loop que anexa ações ilimitadas a uma única lista TransactItems.
  • Fan-out que excede 100 — uma operação lógica que abrange mais de 100 itens e foi modelada como uma única transação.
  • Contando apenas escritas - lembre-se de que as ações do ConditionCheck também contam até 100.

Como corrigir

  1. Dividir em múltiplas transações de ≤100 ações cada — observando que cada transação é independentemente atômica (elas não são revertidas juntas).
  2. Reconsidere se você precisa de uma transação — se as escritas não exigirem semântica de tudo ou nada, BatchWriteItem (≤25 por chamada) é mais barato e mais amigável em termos de rendimento.
  3. Reduza a contagem de ações — junte múltiplas mutações em um item em um único Update com um UpdateExpression combinado.
  4. Modele o agregado de maneira diferente para que uma única mudança lógica afete menos itens.
  5. Observe o limite de tamanho agregado de item de 4 MB junto com o limite de 100 ações — itens grandes podem falhar mesmo abaixo de 100 ações.

Reproduza

Uma transação com 101 ações, uma acima do limite. A rejeição é um ValidationException simples no comprimento do array, não um erro específico da transação:

const actions = Array.from({length: 101}, (_, i) => ({
  Put: {TableName: 'orders', Item: {pk: {S: `T#${i}`}, sk: {S: 'META'}}}
}));
await client.send(new TransactWriteItemsCommand({TransactItems: actions}));

Observe o texto: DynamoDB rejeita isso como uma restrição de comprimento no array TransactItems, então a string que você obtém não contém nenhuma menção a transações. Obviamente, pesquisar a mensagem por si só não o levará até aqui.

Workbench do DynoTable

Antes de confirmar mais de 100 escritas atomicamente, inspecione os itens de destino em DynoTable - abra a tabela com ⌘K e confirme a existência de cada chave. O teste (⌘S) permite testar primeiro uma transação menor.

Crie atualizações de vários itens no Expression Builder e dobre ações duplicadas em uma chave em um único Update. Alternar perfis com ⌘P; consulte Conectar ao AWS e Instalar.

Fontes

Erros relacionados

Referências

Última verificação em 13/07/2026 em relação à documentação oficial do AWS vinculada acima.

Reproduzido em 26/07/2026 em DynamoDB Local 2.x com AWS SDK para JavaScript v3.1095.0 - a saída acima é literal.

ValidationException: Member must have length less than or equal to 100
HTTP 400

Trabalhe com o DynamoDB sem o Console

Um cliente desktop rápido para DynamoDB que roda o SQL de verdade que o DynamoDB não consegue — JOINs, GROUP BY, agregações — com edição visual e um agente de IA com suas próprias chaves do Bedrock.

Teste grátis de 30 dias, sem cartão de crédito — depois o plano Grátis sem limite de tempo.