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: 1 validation error detected: Value '<your request>' at 'transactItems' failed to satisfy constraint: Member must have length less than or equal to 100

The service echoes your entire serialized request where <your request> sits — for a 101-action transaction that is roughly 65,000 characters. The finding is the last sentence.

TransactWriteItems groups actions that all commit or all roll back together, but a single transaction can hold at most 100 actions, and the aggregate size of the items in the transaction cannot exceed 4 MB. 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

Split into multiple transactions of ≤100 actions each — noting each transaction is independently atomic (they don't roll back together).
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.
Reduce action count — fold multiple mutations to one item into a single Update with a combined UpdateExpression.
Model the aggregate differently so a single logical change touches fewer items.
Watch the 4 MB aggregate item-size cap alongside the 100-action limit — large items can fail even below 100 actions.

Reproduce it

A transaction with 101 actions, one over the limit. The rejection is a plain ValidationException on the array length, not a transaction-specific error:

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}));

Real output:

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

Note the wording: DynamoDB rejects this as a length constraint on the TransactItems array, so the string you get contains no mention of transactions at all. Searching the message alone will not obviously lead you here.

DynoTable workbench

Before you commit 100+ writes atomically, inspect the target items in DynoTable — open the table with ⌘K and confirm each key exists. Staging (⌘S) lets you test a smaller transaction first.

Build multi-item updates in the Expression Builder and fold duplicate actions on one key into a single Update. Switch profiles with ⌘P; see Connect to AWS and Install.

Sources

TransactWriteItems — Amazon DynamoDB API Reference (verified 2026-07-13)
Amazon DynamoDB Transactions: How it works (verified 2026-07-13)

Transaction request cannot include multiple operations on one item — the same item targeted twice in a transaction.
TransactionCanceledException — a valid transaction cancelled at commit.
Too many items requested for the BatchWriteItem call — the non-transactional batch limit (25).
Code example: TransactWriteItems in Node.js — a correctly-sized transaction to start from.
Learn: DynamoDB transactions · Batch operations

References

Last verified 2026-07-13 against the official AWS documentation linked above.

Reproduced 2026-07-26 against DynamoDB Local 2.x with AWS SDK for JavaScript v3.1095.0 — the output above is verbatim.