Error: DynamoDB failedbatch retry

A failed batch needs inspection of both the exception and any unprocessed requests. BatchWriteItem can return success while leaving UnprocessedItems; Java SDK 1.x DynamoDBMapper also reports failures through FailedBatch objects.

With the v3 document client, retry the returned subset with a bounded backoff loop. This example starts with one request; build your input batch within the API limits:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, BatchWriteCommand } from "@aws-sdk/lib-dynamodb";

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}));

let pending = {
  Orders: [{ PutRequest: { Item: { pk: "CUSTOMER#123", sk: "ORDER#42" } } }],
};
for (let attempt = 0; attempt < 5; attempt++) {
  const result = await db.send(new BatchWriteCommand({ RequestItems: pending }));
  pending = result.UnprocessedItems ?? {};
  if (Object.keys(pending).length === 0) break;
  await new Promise(resolve => setTimeout(resolve, Math.random() * 100 * 2 ** attempt));
}
if (Object.keys(pending).length > 0) {
  throw new Error("Batch incomplete; preserve pending requests for recovery");
}

The retry count and delay are application examples. Persist or return the remaining requests before abandoning the job. Do not replay already completed writes unnecessarily, and do not retry unchanged validation failures. A thrown SDK exception also needs handling; it is not represented by this successful-response loop.

For Java v1 FailedBatch, inspect getException() and getUnprocessedItems(). For current Java code, use the Enhanced Client batch result and its unprocessed-item accessors. Diagnose hot keys, table or GSI capacity, and configured throughput limits if throttling persists. BatchWriteItem does not support per-item conditions.

See batch-write handling and AWS documentation.