InternalServerError (HTTP 500)

In breve — DynamoDB non è riuscito a elaborare la richiesta; il guasto è lato servizio e riprovare è la risposta documentata — AWS afferma che questi errori sono attesi durante la vita di una tabella e le richieste fallite possono essere riprovate immediatamente. L'unica sottigliezza: un 500 su una scrittura è ambiguo (potrebbe essere riuscita o fallita), quindi rileggi l'Item o usa un pattern idempotente prima di riapplicarla alla cieca.

Cosa significa

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

A differenza degli errori della serie 400 su questo hub, un 5xx non significa che la tua richiesta fosse errata — significa che DynamoDB ha incontrato un guasto interno gestendola. Il correlato ServiceUnavailable (HTTP 503) segnala un problema di disponibilità temporaneo ed è anch'esso ripetibile. Gli AWS SDK riprovano già entrambi automaticamente con backoff esponenziale, quindi tipicamente vedrai un 500 emergere solo dopo che i retry dell'SDK sono stati esauriti.

Perché accade

Guasti transitori lato servizio — AWS documenta che occasionali errori interni sono attesi durante la vita di una tabella; non sono causati dalla forma della tua richiesta.
Un vero evento di servizio — se le risposte 5xx persistono attraverso i retry, controlla l'AWS Health Dashboard per un problema operativo nella tua Region.

Come correggerlo

Riprova con backoff esponenziale — o semplicemente lascia che lo faccia l'SDK; ogni AWS SDK riprova automaticamente le risposte 5xx. Solo dopo un fallimento persistente dovresti trattarlo come un incidente.
Gestisci l'ambiguità della scrittura — un 500 su PutItem/UpdateItem/DeleteItem potrebbe essere stato applicato. Le opzioni documentate:
- rileggi lo stato dell'Item prima di riprovare, e/o
- proteggi il retry con un'espressione di condizione così resti corretto sia che il primo tentativo sia andato a buon fine o meno, es. un controllo di versione:
```
ConditionExpression: 'version = :expected',
ExpressionAttributeValues: {':expected': {'N': '7'}}
```
- usa TransactWriteItems con un ClientRequestToken quando l'idempotenza è un requisito rigoroso — i tentativi duplicati entro la finestra del token contano una volta.
Un 500 su TransactWriteItems è sicuro da riprovare così com'è — la transazione o è stata committata o no; il token deduplica.
Fai escalation solo quando persiste — un 5xx prolungato per minuti è un problema di servizio: controlla la health dashboard e apri un caso di supporto con il RequestId dalle risposte fallite.

Dopo una scrittura ambigua, guarda cosa è effettivamente memorizzato prima di rieseguire il tuo job — l'app desktop DynoTable mostra lo stato live dell'Item a colpo d'occhio, e il calcolatore dei prezzi DynamoDB aiuta a dimensionare il traffico di retry se stai rieseguendo un batch.

Errori correlati

ThrottlingException — il 400 ripetibile che sembra simile ma ha una causa di capacità.
TransactionInProgressException — tempistica di retry sulle transazioni.
Impara: DynamoDB consistency

References

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.