.NET环境下AWS Lambda如何返回错误使SQS消息留存队列

抛出异常后SQS消息仍被删除的问题，核心原因基本集中在以下几点：

• 最常见的诱因：SQS事件源映射开启了*批次项失败报告（ReportBatchItemFailures）*功能。该功能开启后，Lambda服务的判定逻辑会发生变化：默认认为整批消息全部处理成功，仅以函数返回值中上报的失败消息ID作为重试依据，此时即使函数抛出未处理异常，也不会触发整批消息回退，反而会直接删除所有拉取到的消息。
• 函数签名错误：如果handler使用async void作为返回类型，异步执行过程中抛出的异常无法被.NET Lambda运行时捕获，会直接向Lambda服务返回执行成功的响应，触发消息删除。
• 配置不匹配：Lambda函数的超时时间大于SQS队列的可见性超时时间，函数还未执行完成返回异常，消息已经过了可见性周期被重复投递/被其他消费端处理删除。
• 依赖包版本bug：早期版本的Amazon.Lambda.SQSEvents、Amazon.Lambda.Serialization.SystemTextJson存在异常捕获逻辑缺陷，极端场景下无法将异常正确上报给Lambda服务。

你提供的代码：

public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
    throw new Exception ("Whole point of this function is that is retriable in case of error. Why I am deleted from the queue if exception is thrown?");
}

仅在事件源映射未开启批次项失败报告、函数超时小于SQS可见性超时、依赖包为稳定版本的前提下，才能实现消息保留在队列等待重试的效果。只要触发上述任意一个异常诱因，这段代码都无法达到预期。

根据是否开启批次项失败报告，实现方式分为两类：

• 未开启批次项失败报告（整批成功/整批重试模式）
  直接将未处理的业务异常抛出到handler入口即可，不要在全局加catch吞掉异常，Lambda运行时捕获到未处理异常后，会自动将整批消息返回队列，等待可见性超时后重新投递。
• 开启批次项失败报告（支持部分消息重试模式）
  无论整批失败还是部分失败，都不要通过抛异常的方式上报错误，必须返回SQSBatchResponse类型，显式列出所有处理失败的消息ID。
  整批失败的示例代码：

  public async Task<SQSBatchResponse> FunctionHandler(SQSEvent evnt, ILambdaContext context)
  {
      // 业务逻辑执行，判定需要整批重试
      var failedItems = evnt.Records.Select(record => new SQSBatchResponse.BatchItemFailure
      {
          ItemIdentifier = record.MessageId
      }).ToList();
  
      return new SQSBatchResponse
      {
          BatchItemFailures = failedItems
      };
  }
  

  部分失败的场景下，只需要将实际处理失败的消息ID加入BatchItemFailures列表即可，处理成功的消息会被自动删除，无需额外操作。

额外避坑说明 #

• 不要在handler内部写全局try-catch把所有异常吞掉后返回空响应，这会被Lambda判定为执行成功，直接删除消息。
• 不要使用void或async void作为handler返回类型，会导致异常无法被运行时正确捕获。
• 若不需要部分重试能力，不要随意开启事件源映射的批次项失败报告开关，避免出现异常抛出但消息被删的非预期行为。

内容的提问来源于stack exchange，提问作者Vlado Pandžić