Errore server interno (HTTP 500)

TL;DR — DynamoDB non ha potuto elaborare la richiesta; l'errore è dal lato del servizio e il nuovo tentativo è la risposta documentata - AWS afferma che questi errori sono previsti durante la vita di una tabella e le richieste non riuscite possono essere ritentate immediatamente. L'unica sottigliezza: un 500 su write è ambiguo (potrebbe aver avuto successo o fallito), quindi rileggi l'elemento o usa un modello idempotente prima di riapplicarlo ciecamente.

Cosa significa

InternalServerError: The server encountered an internal error trying to
fulfill the request.
HTTP 500 — retryable service-side Exception (Programming.Errors)

A differenza degli errori della serie 400 su questo hub, un 5xx non significa che la tua richiesta era sbagliata: significa che DynamoDB ha riscontrato un errore interno gestendolo. Il relativo "ServiceUnavailable" (HTTP 503) segnala un problema di disponibilità temporaneo ed è anch'esso riprovabile. Gli AWS SDK riprovano già entrambi automaticamente con backoff esponenziale, quindi in genere vedrai solo una superficie 500 dopo che i tentativi dell'SDK sono stati esauriti.

Perché succede

Errori transitori lato servizio — AWS documenta che sono previsti errori interni occasionali durante la vita di una tabella; non sono causati dalla forma della tua richiesta.
Un vero evento di servizio: se le risposte 5xx persistono tra i tentativi, controlla il AWS Health Dashboard per un problema operativo nella tua regione.

Come risolverlo

Riprova con backoff esponenziale o lascia semplicemente che lo faccia l'SDK; ogni AWS SDK riprova automaticamente 5xx risposte. Solo dopo un fallimento persistente dovresti trattarlo come un incidente.
Gestisci l'ambiguità di scrittura: potrebbe essere stato applicato un 500 su PutItem/UpdateItem/DeleteItem. Le opzioni documentate:
- leggere lo stato dell'oggetto prima di riprovare e/o
- proteggi il nuovo tentativo con un'espressione condizionale in modo che rimanga corretto indipendentemente dal fatto che il primo tentativo sia andato a buon fine o meno, ad es. un controllo della versione:
```
ConditionExpression: 'version = :expected',
ExpressionAttributeValues: {':expected': {'N': '7'}}
```
- usa TransactWriteItems con un ClientRequestToken quando l'idempotenza è un requisito difficile: i tentativi duplicati all'interno della finestra del token vengono conteggiati una volta.
Un 500 su TransactWriteItems può essere riprovato così com'è: la transazione è stata confermata oppure no; il token viene deduplicato.
Incrementa solo quando il problema persiste: sostenuto per 5xx minuti è un problema del servizio: controlla il dashboard dell'integrità e apri un caso di supporto con il RequestId dalle risposte con esito negativo.

Dopo una scrittura ambigua, controlla cosa è effettivamente memorizzato prima di eseguire nuovamente il tuo lavoro: l'DynoTable app desktop mostra a colpo d'occhio lo stato dell'elemento attivo e il DynamoDB calcolatore dei prezzi aiuta a dimensionare il traffico dei nuovi tentativi se stai rigestendo un batch.

Prima di riprovare in DynoTable

Dopo 500 in scrittura, apri l'oggetto in DynoTable e leggi lo stato live prima di riprendere il lavoro. La gestione temporanea (⌘S) ti consente di preparare una modifica correttiva e rivedere la differenza prima del commit, in modo più sicuro rispetto alla riproduzione cieca di PutItem. Il cambio di profilo (⌘P) mantiene i tentativi sullo stesso account/regione che ha riscontrato l'errore.

Se stai riproducendo un batch, dimensiona il traffico extra con il calcolatore dei prezzi e controlla la forma dell'elemento con il calcolatore della dimensione dell'articolo. 5xx persistenti nei minuti sono un problema di salute AWS; mantieni il "RequestId" dalle risposte dell'SDK non riuscite per il supporto.

Fonti

Gestione degli errori con DynamoDB — InternalServerError (verificato il 13-07-2026)

Errori correlati

ThrottlingException: il 400 riprovabile che sembra simile ma ha una causa di capacità.
TransactionInProgressException - riprova i tempi sulle transazioni.
Impara: DynamoDB consistenza

Riferimenti

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