GCP PubSub推送订阅对接Cloud Run如何正确ack消息？

核心规则澄清 #

PubSub Push模式下，不需要手动调用message.ack()方法做确认——和Pull模式用客户端消费的逻辑不同，Push模式的消息确认完全依赖推送端点返回的HTTP响应：只要服务在配置的ack截止时间内，返回完整的2xx状态码空响应，PubSub就会自动确认消息，不会再重投。
返回200仍然触发重投，本质是PubSub没有收到符合要求的有效ack响应，和代码里没写ack调用无关。

高频触发原因（按出现概率排序） #

• ack截止时间短于实际请求处理时长：PubSub Push订阅默认的ack截止时间只有10秒，只要从消息发出到PubSub收到完整有效响应的时间超过这个阈值，哪怕最后返回了200，PubSub也会提前判定消息处理失败、触发重投。Cloud Run冷启动加载依赖、业务逻辑耗时过长是这个问题的最常见诱因。
• 响应不符合规范被PubSub拒绝：如果服务返回3xx重定向（比如全局开启了斜杠补全跳转，/run跳转到/run/）、响应体大小超过100KB、响应被中间件截断，PubSub都不会把这个响应当作有效ack。
• 配置不匹配导致响应没被接收：Cloud Run的请求超时时间如果短于PubSub的ack截止时间，Cloud Run会提前断开连接，PubSub收不到完整响应；如果Push订阅配置了服务账号鉴权，但Cloud Run未给对应账号开放调用权限，或者自定义鉴权中间件拦截了PubSub的推送请求返回4xx/5xx，也会直接触发重投。
• 未捕获的异步异常中断响应：如果业务逻辑里存在未await的异步操作、浮动Promise抛出未捕获异常，可能导致响应链路中断，PubSub收不到完整的200响应。

修复&排查步骤 #

1. 先核对基础配置
   • 进入PubSub订阅详情页，把确认截止时间调整为服务P99请求耗时+3~5秒冗余，最大可设为600秒；同时确认推送端点路径完全匹配，不要多/少斜杠、漏路径。
   • 进入Cloud Run服务详情页，把服务请求超时时间设置为比PubSub ack截止时间长至少1倍，避免Cloud Run提前断连；如果冷启动耗时高，可以把最小实例数设为1，消除冷启动影响。
2. 调整服务代码，添加可观测性
   修正后的Express处理代码参考如下，重点是正确配置body解析器、明确返回空响应、添加日志对齐消息ID排查：

// 配置JSON解析器，适配PubSub最大10MB的消息体限制
app.use(express.json({ limit: '10mb' }));

app.post('/run', async (req, res) => {
  const processStart = Date.now();
  // 提取PubSub自带的消息ID，方便对齐日志排查重复投递
  const msgId = req.body?.message?.messageId || 'unknown-msg';
  console.log(`Start processing message: ${msgId}`);

  try {
    // 原有消息解析逻辑
    const rawBody = req.body.message 
      ? Buffer.from(req.body.message.data, 'base64').toString() 
      : req.body;
    const parsedMsg = JSON.parse(rawBody);

    // 业务逻辑注意：所有异步操作必须加await，不要留浮动Promise
    // await yourBusinessLogic(parsedMsg);

    // 返回标准空200响应，明确设置Content-Length为0，避免多余响应体
    res.status(200).set('Content-Length', '0').end();
    console.log(`Process message ${msgId} success, cost: ${Date.now() - processStart}ms`);
  } catch (err) {
    console.error(`Process message ${msgId} failed:`, err);
    // 业务异常返回5xx，触发PubSub按配置的重试策略重投
    res.status(500).end();
  }
});

3. 日志定位根因
   用重复投递的消息ID搜索Cloud Run日志，核对每一次请求的：
   • 实际处理耗时，如果超过ack截止时间，要么优化业务逻辑速度，要么继续调大ack截止时间
   • 实际返回状态码，如果是3xx/4xx，检查全局重定向规则、鉴权中间件，可通过PubSub推送请求自带的APIS-Google User-Agent头做放行规则
   • 有没有未捕获的异常日志，补全所有异步操作的await和异常捕获

优化建议 #

• 配置死信队列，超过最大重试次数的异常消息会自动进入死信，不会无限重投占用资源
• 如果业务逻辑本身耗时长，不适合用Push模式同步处理，可以改成Pull模式搭配异步消费，或者把消息先持久化再异步处理，避免请求耗时过长触发ack超时

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