AWS SQS FIFO消息未触发重试，请求排查原因

核心逻辑排查与修正 #

你的轮询思路方向是对的，但几个细节可能导致重试未触发：

1. Lambda错误处理方式不符合SQS重试规则 #

SQS判定消息需要重试的前提是：Lambda抛出未捕获的异常，或者批量处理时明确标记消息处理失败。如果你的错误被捕获后手动抛出但未被运行时识别为“处理失败”，或是用try/except吞掉异常后返回成功，SQS会直接认为消息已处理完成并删除。

• 修正：确保函数抛出未被捕获的异常，比如Python里直接raise Exception("Entity pending")，不要自行捕获异常后返回成功状态。

2. SQS队列的重试限制配置 #

如果你的队列设置了最大接收次数（Maximum Receives），当消息被接收次数超过阈值，会被移至死信队列（DLQ），不会再进入重试流程。

• 排查：去SQS控制台查看队列的死信队列配置，检查死信队列里是否有目标消息；如果不需要死信队列，可暂时将最大接收次数设为0（允许无限重试），或按1小时保留期设置为30次（每2分钟一次）。

3. Lambda批量处理设置干扰 #

默认Lambda会批量接收SQS消息，若批量大小大于1，单条消息失败可能导致整个批次被标记为失败并重新入队，但如果你的代码手动处理批量消息时逻辑有误，可能导致目标消息被误判为处理成功。

• 修正：将Lambda的批量大小（Batch Size）设为1，确保单条消息的失败逻辑独立，重试流程更清晰。

4. 可见性超时与Lambda超时的合理性 #

你设置的Lambda超时1分钟、SQS可见性超时2分钟是合理的（可见性超时需≥Lambda超时，避免消息被重复处理），但需确认Lambda抛出错误前的执行时间未超过1分钟——若函数被强制终止，SQS也会触发重试，但你提到日志显示函数正常抛错，这个因素可暂不优先排查。

验证手段 #

• 查看SQS队列统计：在控制台查看「Approximate Number of Visible Messages」和「Approximate Number of Invisible Messages」，若消息处于Invisible状态，说明正在等待可见性超时，之后会重试；若计数为0，要么被删除，要么被移至死信队列。
• 检查死信队列：若配置了DLQ，查看其中是否有目标消息，确认是否因超过最大接收次数被转移。
• 增加日志维度：在Lambda中打印消息的ReceiptHandle和attributes.ApproximateReceiveCount（接收次数），直接确认消息被触发的次数。

优化建议 #

• 不要依赖无限重试，给SQS设置合理的最大接收次数和死信队列，避免消息无限循环。比如按1小时保留期设置30次最大接收次数，超过后移至DLQ便于排查。
• 可根据ApproximateReceiveCount动态调整消息可见性超时（通过Lambda调用ChangeMessageVisibilityAPI），减少高频率的API调用，不过会增加代码复杂度。

内容的提问来源于stack exchange，提问作者Matt Dietsche