InternalServerError (HTTP 500)

TL;DR — DynamoDB 無法處理請求；故障在服務端，而重試是記載的因應方式 — AWS 表示這些錯誤在表格的生命週期中是預期的，失敗的請求可立即重試。唯一的微妙之處：_寫入_上的 500 是模稜兩可的（它可能成功也可能失敗），因此在盲目重新套用前，先讀回項目或使用冪等模式。

這是什麼意思

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

與這個中心的 400 系列錯誤不同，5xx 不代表你的請求有誤 — 它代表 DynamoDB 在處理它時碰到內部故障。相關的 ServiceUnavailable（HTTP 503）代表暫時的可用性問題，同樣可重試。AWS SDK 已以指數退避自動重試兩者，因此你通常只會在 SDK 的重試用盡後才看到 500 浮現。

為什麼會發生

• 暫時性的服務端故障 — AWS 記載偶發的內部錯誤在表格生命週期中是預期的；它們並非由你的請求形狀造成。
• 真正的服務事件 — 若 5xx 回應在多次重試後仍持續，查看 AWS Health Dashboard 是否有你 Region 的營運問題。

如何修正

1. 以指數退避重試 — 或就讓 SDK 去做；每個 AWS SDK 都自動重試 5xx 回應。只有在持續失敗後，才將它視為事件。
2. 處理寫入的模稜兩可 — PutItem/UpdateItem/DeleteItem 上的 500 可能已被套用。記載的選項：

   • 在重試前讀取項目的狀態，且/或

   • 以 condition expression 防護重試，讓它無論第一次嘗試是否落地都保持正確，例如版本檢查：

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

   • 當冪等性是硬性要求時，使用帶 ClientRequestToken 的 TransactWriteItems — token 視窗內的重複嘗試只計一次。

3. TransactWriteItems 上的 500 原樣可安全重試 — 交易要嘛已提交、要嘛沒有；token 會去重。
4. 只在持續發生時升級處理 — 持續數分鐘的 5xx 是服務問題：查看 health dashboard 並以失敗回應中的 RequestId 開啟支援案件。

在模稜兩可的寫入後，先看看實際儲存了什麼再重新執行你的工作 — DynoTable 桌面應用程式一眼顯示即時項目狀態，而 DynamoDB 定價計算器在你重新驅動批次時協助估算重試流量。

相關錯誤

• ThrottlingException — 看起來相似但有容量原因的可重試 400。
• TransactionInProgressException — 交易的重試時機。
• 學習：DynamoDB consistency

References

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

最後驗證於 2026-07-13，對照上方連結的 AWS 官方文件。