Dataflow流式管道无报错但未读数据、未启动worker排查

这个故障和MongoDB、BigQuery侧的管道读写逻辑无关，核心本质是Dataflow服务账号权限缺失，触发了基础设施拉起的死循环：

• 日志里的错误码13对应GCE的PERMISSION_DENIED（权限拒绝），「实例模板已存在」是重试过程产生的表象日志，不是核心问题。
• Dataflow启动作业拉起worker前，会先在项目下生成、校验对应规格的GCE实例模板：
  1. 你代码中配置的服务账号my_sa缺少compute.instanceTemplates.get权限，Dataflow无法查询目标实例模板是否存在，会持续误判模板不存在，反复发起创建请求
  2. 同名实例模板实际是历史作业或其他流程留存的已有资源，因此每次创建请求都会直接返回「资源已存在」的报错
  3. 同时服务账号缺少实例模板使用、虚拟机创建的相关权限，既无法复用已存在的模板，也无法跳过模板步骤拉起worker，就会卡在每分钟一次的重试循环中，始终不会创建worker、启动数据读取流程，作业前端页面因为还没进入数据处理阶段，不会展示可见错误。
• 如果你在beam_args中手动指定了固定的自定义实例模板，且模板所属区域和配置的my_region不匹配，也会触发同类查询失败、重复创建的重试逻辑。

1. 给配置的Dataflow服务账号my_sa绑定项目级Dataflow Worker基础角色，也可以最小化补齐以下必要权限：
   • compute.instanceTemplates.get
   • compute.instanceTemplates.list
   • compute.instanceTemplates.create
   • compute.instanceTemplates.useReadOnly
   • compute.instances.create
   • compute.instances.list
   • compute.subnetworks.use
2. 进入GCE实例模板控制台，删除所有名称和当前卡住作业的my_job_name前缀匹配的历史残留自动生成模板，清除资源名冲突。
3. 如果使用共享VPC子网，需要额外确认该服务账号在共享VPC的宿主项目中拥有对应子网的使用权限。
4. 停止当前卡住的作业，重新提交即可正常拉起worker，开始执行MongoDB到BigQuery的同步。

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