Too many actions in a TransactWriteItems call

TL;DR — A DynamoDB transaction is capped at 100 actions. TransactWriteItems (and TransactGetItems) reject a request with more than 100 Put/Update/Delete/ConditionCheck actions. Split the work into multiple transactions — or, if you don't need all-or-nothing atomicity, use BatchWriteItem (25 per call) instead.

What it means

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

TransactWriteItems groups actions that all commit or all roll back together, but a single transaction can hold at most 100 actions (the limit was raised from 25 to 100). Pass more and DynamoDB rejects the whole call before executing. The message often reads as a constraint on the TransactItems list length. It's an HTTP 400 ValidationException, client-side, and not retryable until the transaction is smaller.

Why it happens

  • Batching too many writes atomically — trying to commit 150 puts in one transaction.
  • A loop that appends unbounded actions to a single TransactItems list.
  • Fan-out that exceeds 100 — one logical operation that touches more than 100 items and was modeled as a single transaction.
  • Counting only writes — remember ConditionCheck actions count toward the 100 too.

How to fix it

  1. Split into multiple transactions of ≤100 actions each — noting each transaction is independently atomic (they don't roll back together).
  2. Reconsider whether you need a transaction at all — if the writes don't require all-or-nothing semantics, BatchWriteItem (≤25 per call) is cheaper and throughput-friendlier.
  3. Reduce action count — fold multiple mutations to one item into a single Update with a combined UpdateExpression.
  4. Model the aggregate differently so a single logical change touches fewer items.

Lavora con DynamoDB senza la Console

DynoTable è un client desktop veloce per DynamoDB — sfoglia le tabelle, esegui query in stile SQL e modifica gli Item localmente.