InternalServerError (HTTP 500)

TL;DR — DynamoDB n'a pas pu traiter la requête ; la panne est du côté du service et réessayer est la réponse documentée — AWS indique que ces erreurs sont attendues pendant la durée de vie d'une table et que les requêtes échouées peuvent être réessayées immédiatement. La seule subtilité : un 500 sur une écriture est ambigu (elle peut avoir réussi ou échoué), alors relis l'élément ou utilise un motif idempotent avant de le réappliquer aveuglément.

Ce que ça signifie

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

Contrairement aux erreurs de la série 400 de ce hub, un 5xx ne signifie pas que ta requête était incorrecte — il signifie que DynamoDB a rencontré une panne interne en la traitant. L'erreur ServiceUnavailable (HTTP 503) associée signale un problème de disponibilité temporaire et est de même réessayable. Les SDK AWS réessaient déjà les deux automatiquement avec un backoff exponentiel, donc tu ne verras généralement un 500 remonter qu'après épuisement des nouvelles tentatives du SDK.

Pourquoi ça arrive

Pannes transitoires côté service — AWS documente que des erreurs internes occasionnelles sont attendues pendant la durée de vie d'une table ; elles ne sont pas causées par la forme de ta requête.
Un véritable incident de service — si les réponses 5xx persistent malgré les nouvelles tentatives, consulte l'AWS Health Dashboard pour un problème opérationnel dans ta région.

Comment corriger

Réessaie avec un backoff exponentiel — ou laisse simplement le SDK le faire ; chaque SDK AWS réessaie les réponses 5xx automatiquement. Ce n'est qu'après un échec persistant que tu devrais traiter cela comme un incident.
Gère l'ambiguïté d'écriture — un 500 sur PutItem/UpdateItem/DeleteItem peut avoir été appliqué. Les options documentées :
- relire l'état de l'élément avant de réessayer, et/ou
- protéger la nouvelle tentative avec une expression de condition pour qu'elle reste correcte que la première tentative ait abouti ou non, par ex. une vérification de version :
```
ConditionExpression: 'version = :expected',
ExpressionAttributeValues: {':expected': {'N': '7'}}
```
- utiliser TransactWriteItems avec un ClientRequestToken quand l'idempotence est une exigence stricte — les tentatives dupliquées dans la fenêtre du token comptent une seule fois.
Un 500 sur TransactWriteItems est réessayable en l'état — la transaction a soit été validée, soit non ; le token déduplique.
N'escalade que quand ça persiste — un 5xx soutenu sur plusieurs minutes est un problème de service : consulte le health dashboard et ouvre un dossier de support avec le RequestId des réponses en échec.

Après une écriture ambiguë, regarde ce qui est réellement stocké avant de relancer ton job — l'application de bureau DynoTable affiche l'état de l'élément en direct d'un coup d'œil, et le calculateur de tarifs DynamoDB aide à dimensionner le trafic de nouvelles tentatives si tu relances un lot.

Erreurs liées

ThrottlingException — le 400 réessayable qui lui ressemble mais a une cause de capacité.
TransactionInProgressException — timing des nouvelles tentatives sur les transactions.
Apprends : Cohérence DynamoDB

References

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.