InternalServerError (HTTP 500)

TL;DR — DynamoDB não conseguiu processar a solicitação; a falha está no lado do serviço e a nova tentativa é a resposta documentada – AWS afirma que esses erros são esperados durante a vida útil de uma tabela e as solicitações com falha podem ser repetidas imediatamente. A única sutileza: um 500 em uma gravação é ambíguo (pode ter sido bem-sucedido ou falhado), então leia o item novamente ou use um padrão idempotente antes de reaplicá-lo cegamente.

O que significa

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

Ao contrário dos erros da série 400 neste hub, um 5xx não significa que sua solicitação estava errada – significa que o DynamoDB atingiu uma falha interna ao processá-la. O ServiceUnavailable (HTTP 503) relacionado sinaliza um problema de disponibilidade temporário e também pode ser tentado novamente. Os SDKs AWS já tentam ambos automaticamente com espera exponencial, portanto, normalmente você só verá uma superfície 500 depois que as novas tentativas do SDK se esgotarem.

Por que isso acontece

Falhas transitórias do lado do serviço — AWS documenta que erros internos ocasionais são esperados durante a vida útil de uma tabela; eles não são causados pelo formato da sua solicitação.
Um evento de serviço genuíno — se as respostas 5xx persistirem nas novas tentativas, verifique o Painel de integridade do AWS para ver se há um problema operacional em sua região.

Como corrigir

Tente novamente com espera exponencial — ou simplesmente deixe o SDK fazer isso; cada SDK AWS tenta novamente respostas 5xx automaticamente. Somente após uma falha persistente você deve tratá-la como um incidente.
Tratar ambiguidade de gravação — um 500 em PutItem/UpdateItem/DeleteItem pode ter sido aplicado. As opções documentadas:
- leia o estado do item antes de tentar novamente e /or
- guarde a nova tentativa com uma expressão de condição para que ela permaneça correta, independentemente de a primeira tentativa ter ocorrido ou não, por exemplo. uma verificação de versão:
```
ConditionExpression: 'version = :expected',
ExpressionAttributeValues: {':expected': {'N': '7'}}
```
- use TransactWriteItems com um ClientRequestToken quando idempotência for um requisito rígido — tentativas duplicadas dentro da janela do token contam uma única vez.
Um 500 em TransactWriteItems é seguro para tentar novamente como está — a transação ou foi commitada ou não foi; o token deduplica.
Escale apenas quando persistir — 5xx sustentado ao longo de minutos é um problema de serviço: verifique o health dashboard e abra um caso de suporte com o RequestId das respostas que falharam.

Após uma escrita ambígua, olhe o que está de fato armazenado antes de reexecutar seu job — o app desktop DynoTable mostra o estado ao vivo do item num relance, e a calculadora de preços do DynamoDB ajuda a dimensionar o tráfego de retry se você estiver reprocessando um lote.

Antes de tentar de novo no DynoTable

Depois de um 500 em uma escrita, abra o item no DynoTable e leia o estado ao vivo antes de reexecutar o job. O staging (⌘S) permite preparar uma edição corretiva e revisar o diff antes do commit — mais seguro do que repetir PutItem às cegas. A troca de perfil (⌘P) mantém os retries na mesma conta/region que viu a falha.

Se você estiver reprocessando um lote, dimensione o tráfego extra com a calculadora de preços e verifique o formato do item com a calculadora de tamanho de item. 5xx persistente ao longo de minutos é um problema do AWS Health; guarde o RequestId das respostas do SDK que falharam para o suporte.

Fontes

Error handling with DynamoDB — InternalServerError (verificado em 2026-07-13)

Erros relacionados

ThrottlingException — o 400 retentável que parece similar mas tem causa de capacidade.
TransactionInProgressException — tempo de retry em transações.
Aprenda: DynamoDB consistency

Referências

Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima.