InternalServerError (HTTP 500)

TL;DR — DynamoDB no pudo procesar la solicitud; el fallo está del lado del servicio y reintentar es la respuesta documentada — AWS afirma que estos errores son esperables durante la vida de una tabla y que las solicitudes fallidas pueden reintentarse inmediatamente. El único matiz: un 500 en una escritura es ambiguo (puede haber tenido éxito o haber fallado), así que vuelve a leer el Item o usa un patrón idempotente antes de reaplicarlo a ciegas.

Qué significa

InternalServerError: The server encountered an internal error trying to
fulfill the request.

A diferencia de los errores de la serie 400 de este hub, un 5xx no significa que tu solicitud fuera incorrecta — significa que DynamoDB tuvo un fallo interno al manejarla. El error relacionado ServiceUnavailable (HTTP 503) señala un problema temporal de disponibilidad y es igualmente reintentable. Los AWS SDK ya reintentan ambos automáticamente con retroceso exponencial, así que normalmente solo verás aparecer un 500 después de que se agoten los reintentos del SDK.

Por qué ocurre

• Fallos transitorios del lado del servicio — AWS documenta que los errores internos ocasionales son esperables durante la vida de una tabla; no los causa la forma de tu solicitud.
• Un evento de servicio genuino — si las respuestas 5xx persisten entre reintentos, revisa el AWS Health Dashboard por si hay un problema operativo en tu región.

Cómo solucionarlo

1. Reintenta con retroceso exponencial — o simplemente deja que el SDK lo haga; todo AWS SDK reintenta las respuestas 5xx automáticamente. Solo tras un fallo persistente deberías tratarlo como un incidente.
2. Maneja la ambigüedad de escritura — un 500 en PutItem/UpdateItem/DeleteItem puede haberse aplicado. Las opciones documentadas:

   • lee el estado del Item antes de reintentar, y/o

   • protege el reintento con una expresión de condición para que siga siendo correcto tanto si el primer intento aterrizó como si no, p. ej. una comprobación de versión:

     ConditionExpression: 'version = :expected',
     ExpressionAttributeValues: {':expected': {'N': '7'}}

   • usa TransactWriteItems con un ClientRequestToken cuando la idempotencia sea un requisito estricto — los intentos duplicados dentro de la ventana del token cuentan una vez.

3. Un 500 en TransactWriteItems es seguro de reintentar tal cual — la transacción o se confirmó o no; el token deduplica.
4. Escala solo cuando persista — un 5xx sostenido durante minutos es un problema del servicio: revisa el health dashboard y abre un caso de soporte con el RequestId de las respuestas fallidas.

Tras una escritura ambigua, mira lo que hay realmente almacenado antes de reejecutar tu trabajo — la app de escritorio DynoTable muestra el estado en vivo del Item de un vistazo, y la calculadora de precios de DynamoDB ayuda a dimensionar el tráfico de reintentos si estás reejecutando un lote.

Errores relacionados

• ThrottlingException — el 400 reintentable que parece similar pero tiene una causa de capacidad.
• TransactionInProgressException — temporización de reintentos en transacciones.
• Aprende: Consistencia de DynamoDB

Referencias

• Error handling with DynamoDB — Amazon DynamoDB Developer Guide
• TransactWriteItems (ClientRequestToken idempotency) — Amazon DynamoDB API Reference
• Query (InternalServerError, HTTP 500) — Amazon DynamoDB API Reference

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.