SQS批量消息经Lambda成功处理后仍进入DLQ求助

队列配置 #

Type: AWS::SQS::Queue
Properties:
  QueueName: "notification-service-queue.fifo"
  FifoQueue: true
  ContentBasedDeduplication: true
  VisibilityTimeout: 180
  FifoThroughputLimit: perMessageGroupId
  DeduplicationScope: messageGroup 
  RedrivePolicy:
    deadLetterTargetArn: ${self:custom.DLQ_ARN}
    maxReceiveCount: 2

问题现象 #

批量发送10条消息至上述FIFO队列后，Lambda触发执行并返回“Successfully Processed”，但消息未被自动删除，整批消息最终进入死信队列（DLQ）。

可能原因及解决办法 #

1. Lambda未正确完成批量消息处理 #

Lambda批量处理SQS消息时，只有函数全程无未捕获异常、同步逻辑完全执行完毕，SQS才会自动删除整批消息。如果代码中存在隐性异常（如异步操作未等待完成、部分消息处理逻辑出错但未抛出），即使返回成功响应，SQS仍会判定处理失败，消息重回队列，达到maxReceiveCount后进入DLQ。

• 解决：
  • 排查Lambda代码，确保所有批量消息的处理逻辑无异常，异步操作需在函数返回前完成；
  • 若部分消息处理失败，需手动调用DeleteMessageBatch API删除成功处理的消息，单独保留失败消息重试。

2. VisibilityTimeout过短 #

当前队列VisibilityTimeout设为180秒，若Lambda处理批量消息的耗时超过该时长，SQS会认为消息未处理完成，将其重新设为可见状态并再次触发Lambda。重复接收2次后，消息进入DLQ。

• 解决：根据Lambda实际处理耗时调整VisibilityTimeout，建议设为Lambda函数超时时间的1.5-2倍（例如Lambda超时5分钟，该值设为900秒）。

3. 消息组ID分配不合理 #

启用FifoThroughputLimit: perMessageGroupId后，同一消息组的消息会被顺序处理。若批量消息属于同一消息组，其中某条消息的隐性处理异常会导致整批消息被重复重试，最终进入DLQ。

• 解决：
  • 若非必须顺序处理，将消息分配至不同消息组以提升并行处理能力；
  • 检查同一消息组内的消息处理逻辑，消除依赖或隐性错误。

4. Lambda触发器配置问题 #

若Lambda的SQS触发器开启了「报告批量项失败（ReportBatchItemFailures）」，但代码未返回batchItemFailures字段指定失败消息ID，SQS会误判整批处理失败，导致消息重试。

• 解决：
  • 若不需要该功能，关闭「报告批量项失败」选项，此时只要Lambda执行成功，整批消息自动删除；
  • 若需保留该功能，确保代码返回包含batchItemFailures的响应，明确标注处理失败的消息ID。

内容的提问来源于stack exchange，提问作者Abu Tahir