如何让Cloud Run任务在客户端关闭连接后持续运行

核心问题结论 #

1. 无法通过配置让Cloud Run忽略客户端断连持续执行请求内任务 #

Cloud Run有明确的请求生命周期管控规则：

• 你代码里写的req.setTimeout(12000000)仅能修改Express框架层面的请求超时阈值，覆盖不了平台层规则
• 只要客户端主动断开HTTPS连接，对应请求关联的CPU资源会被立刻节流，正在执行的run函数会被直接中断，没有配置可以绕过这个限制
• 客户端切后台被系统回收网络连接、触发自动重试，就是你现在遇到重复调用问题的直接原因

2. 「先返回响应再后台执行run函数」的写法稳定性极差，不建议使用 #

不要在请求响应发回客户端后，继续在同个请求上下文里跑长任务：

• 默认配置下，响应发送完成后Cloud Run会立刻把实例CPU限制到接近0，后台任务会直接卡住甚至终止
• 就算手动开启服务的「CPU始终分配」开关，Cloud Run自动缩容逻辑会在实例无活跃请求时随时回收实例，你跑了一半的10分钟任务会直接丢失，没有任何通知
• 这种写法本身就不符合Cloud Run的服务设计规范，线上用出问题的概率极高

可行落地方案 #

按改造成本从低到高排序：

• 客户端+接口幂等改造（临时缓解）
  • 调整移动端逻辑：应用切后台时不要主动取消未完成的接口请求
  • 给每次请求生成唯一的请求ID，接口侧先校验请求ID：如果对应ID的任务已经在执行/已执行完成，直接返回对应结果，不要重复触发run逻辑
  • 注意Cloud Run默认请求超时是60分钟，你的10分钟任务本身在超时阈值内，这个方案可以解决大部分重复调用问题，但没法彻底规避移动端系统强制杀后台网络连接的场景
• 异步队列解耦（推荐生产使用）
  把长任务从HTTP请求链路里拆出来：
  1. 接口收到请求后，先给任务生成唯一ID，把任务参数存入Cloud Tasks/PubSub队列，立刻给客户端返回「任务已提交」的响应，整个接口响应时间控制在几百毫秒内，完全不依赖长连接
  2. 单独配置Worker消费逻辑（可以复用现有Cloud Run服务，通过队列推送触发），异步拉取队列里的任务执行run逻辑，执行完成后再给移动端推送通知
  3. 队列本身自带任务持久化、失败重试、幂等校验能力，就算实例被回收、客户端断连，任务也不会丢失，是Cloud Run上跑长任务的标准方案
• 单服务持久化兜底（小流量场景可选）
  如果不想引入队列组件，可以开启服务的「CPU始终分配」配置，同时把任务信息、执行状态实时写入Firestore/Cloud SQL等持久化存储：收到请求后先存任务记录、立刻返回响应，后台执行任务时同步更新状态，再配置Cloud Scheduler定时扫描超时未完成的任务补跑即可。这个方案需要自己处理任务重复执行、中断恢复的逻辑，维护成本比用队列高。

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