AWS Lambda处理SQS队列触发器时在16次递归后停止

更新：发现AWS判定程序处于递归循环，存在Recursive invocations dropped指标，当该指标达到16时Lambda停止处理，解决后会同步答案。

问题场景 #

配置SQS队列作为Lambda的事件源映射，Lambda负责批量处理S3文件数据，每次处理100行，目标文件包含10000+条数据。

处理流程 #

• 处理100行数据
• 发送起止参数到SQS，创建新任务处理下100行

流程在处理1600条数据前均正常，但每次都会在该节点失败。最后一条日志显示SQS消息发送成功，Lambda也正常结束：

2024/06/30/[$LATEST]82e77466cf99479ca05c453e6da39436 2024-06-30T00:25:39.579000 {
  "timestamp": "2024-06-30T00:25:39.579Z",
  "level": "INFO",
  "requestId": "2035819e-7b43-5e5f-9d0a-df64dcbed81a",
  "message": {
    "message": "Processing batch 1601-1700 of contacts-full16.csv",
    "data": {
      "$metadata": {
        "httpStatusCode": 200,
        "requestId": "9b5e2cfe-21cd-5649-9ade-7204898e4803",
        "attempts": 1,
        "totalRetryDelay": 0
      },
      "MD5OfMessageAttributes": "793a908cbea235c2c3fbfed4b9ee333a",
      "MD5OfMessageBody": "c98b6d9c345a46fccf6d6cc6d92e99e9",
      "MessageId": "99a6d3bc-d0b3-41cd-882f-28ffc3064dd0"
    }
  }
}
2024/06/30/[$LATEST]82e77466cf99479ca05c453e6da39436 2024-06-30T00:25:39.581000 {
  "time": "2024-06-30T00:25:39.581Z",
  "type": "platform.report",
  "record": {
    "requestId": "2035819e-7b43-5e5f-9d0a-df64dcbed81a",
    "metrics": {
      "durationMs": 50593.656,
      "billedDurationMs": 50594,
      "memorySizeMB": 512,
      "maxMemoryUsedMB": 145
    },
    "tracing": {
      "spanId": "15844fe56191b17e",
      "type": "X-Amzn-Trace-Id",
      "value": "Root=1-6680a5d0-5d097410faf01195360c7e44;Parent=5c5e05fe243ddd01;Sampled=1"
    },
    "status": "success"
  }
}

Lambda与前15-16次执行一样成功退出，队列显示有1条消息在处理中，但死信队列（DLQ）无消息。

CloudFormation(SAM)配置 #

Resources:
  DeadLetterQueue:
    Type: AWS::SQS::Queue
    UpdateReplacePolicy: Delete
    DeletionPolicy: Delete

  SQSQueue:
    Type: AWS::SQS::Queue
    UpdateReplacePolicy: Delete
    DeletionPolicy: Delete
    Properties:
      QueueName: my-queue
      MessageRetentionPeriod: 86400
      VisibilityTimeout: 1800
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt DeadLetterQueue.Arn
        maxReceiveCount: 3
  
  SQSQueueHandler:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/handlers/
      Handler: sync.lambdaHandler
      Runtime: nodejs20.x
      MemorySize: 512
      Timeout: 300
      Policies:
        - AmazonSQSFullAccess
     
  LambdaFunctionEventSourceMapping:
    Type: AWS::Lambda::EventSourceMapping
    Properties:
      BatchSize: 10
      Enabled: true
      EventSourceArn: !GetAtt SQSQueue.Arn
      FunctionName: !GetAtt SQSQueueHandler.Arn

已尝试的排查步骤 #

• 重复执行4次，均在同一节点失败
• 调整SQS批量大小和Lambda并发数，无效果
• 将行处理代码替换为占位代码，问题依旧
• 第16条SQS请求始终无法被Lambda拾取

解决思路 #

1. 针对递归循环限制的验证：

   • 查看Lambda控制台的Recursive invocations dropped指标，确认是否达到16次触发了AWS的递归防护机制。Lambda默认会检测同一请求链中的递归调用，达到阈值时会阻止后续调用。
   • 向SQS发送消息时，手动修改X-Amzn-Trace-Id的Root值，打破原有的递归追踪链，避免被判定为递归调用。

2. SQS消息消费逻辑检查：

   • 手动调整第16条消息的可见性超时，验证是否能被Lambda正常拾取。当前队列VisibilityTimeout为1800秒，远大于Lambda超时300秒，理论上不会锁定消息，但可尝试重置可见性。
   • 给Lambda事件源映射添加MaximumBatchingWindowInSeconds参数（如设置为1秒），强制缩短消息批量等待时间，触发Lambda拾取。

3. 替换递归触发模式：

   • 改用Step Functions编排批量处理流程，通过状态机控制任务迭代，避免Lambda递归防护限制，同时获得更直观的流程监控和错误处理能力。
   • 改为Lambda内部循环分页处理S3数据，无需依赖SQS触发后续任务，减少中间环节的限制。

4. AWS官方渠道排查：

   • 若以上方法无效，提交AWS Support工单，提供完整日志、指标和配置信息，让官方技术团队确认是否存在账户/区域特定限制，或是Lambda事件源映射的隐藏逻辑导致问题。

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