PubSub消息触发Python Cloud Run后无法确认，重试次数超限

1. 验证Terraform订阅配置的正确性 #

• 检查google_pubsub_subscription资源中ack_deadline_seconds是否明确设为60，且dead_letter_policy块配置完整：

  resource "google_pubsub_subscription" "main" {
    name  = "your-subscription"
    topic = google_pubsub_topic.main.name
  
    ack_deadline_seconds = 60
  
    dead_letter_policy {
      dead_letter_topic     = google_pubsub_topic.dead_letter.name
      max_delivery_attempts = 5
    }
  }
  

• 确认dead_letter_topic指向已存在的死信主题，且Terraform apply过程无隐性报错（比如权限不足导致死信策略未生效）。

2. 检查Cloud Run的204响应是否符合PubSub要求 #

• PubSub仅接受无响应体的204状态码，若返回空JSON、空字符串或多余响应头，会被判定为确认失败：
  • 错误示例（Flask）：return jsonify({}), 204（会生成Content-Type: application/json和空JSON体）
  • 正确示例：return '', 204（确保Content-Length: 0，无额外响应内容）
• 查看Cloud Run的请求日志，确认响应头严格符合要求，无多余字段。

3. 确认订阅的实际生效配置 #

• 不要依赖Terraform代码，直接通过GCP控制台或gcloud命令验证订阅的实际参数：

  gcloud pubsub subscriptions describe your-subscription
  

• 重点检查deadLetterPolicy字段是否存在，maxDeliveryAttempts是否为5，ackDeadlineSeconds是否为60。如果配置未生效，可能是Terraform apply时权限不足（比如缺少pubsub.subscriptions.update权限）。

4. 排查投递计数与超时逻辑 #

• 查看消息的delivery_attempt属性，确认PubSub是否正确计数投递次数。如果计数异常，可能是消息未被正确标记为确认。
• 若Cloud Run处理时间接近60秒，可能出现PubSub在收到204前已触发超时重试。临时将ack_deadline_seconds调整为120秒，测试是否还会持续重试，排除超时导致的重复投递。

5. 验证死信队列的权限配置 #

• 确保PubSub服务账号（service-<项目ID>@gcp-sa-pubsub.iam.gserviceaccount.com）拥有死信主题的roles/pubsub.publisher权限。如果权限不足，消息无法进入死信队列，会一直重试直到被手动确认。
• 通过IAM控制台检查死信主题的权限列表，确认PubSub服务账号已被添加。

内容的提问来源于stack exchange，提问作者Javier Lopez Tomas