Cloud Scheduler触发Cloud Functions时突然返回INVALID_ARGUMENT错误求助

1. 核对函数运行时版本 #

• 确认重部署/新创建的函数是否使用了较新的运行时版本（如Node.js 20+、Python 3.11+），部分新版本对OIDC令牌的验证逻辑有调整，可能导致Scheduler请求参数不兼容。
• 尝试将新函数降级到与旧函数相同的运行时版本，重新部署后测试Scheduler触发。

2. 检查Scheduler的OIDC配置细节 #

• 验证Scheduler任务的受众（Audience）字段是否完全匹配函数的HTTP触发URL：
  • 旧函数的受众通常是https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME，新函数若因同名部署生成带版本后缀的URL，会导致受众不匹配。
  • 手动修改Scheduler任务的受众为新函数的完整触发URL，确保无拼写错误。
• 确认服务账号的令牌有效期配置，部分新部署函数可能默认限制了令牌时长，需调整为不超过函数允许的范围（默认通常为3600秒）。

3. 排查函数的HTTP请求处理逻辑 #

• 尽管手动测试正常，但Scheduler的请求头与手动测试存在差异（如Authorization头格式、Content-Type）：
  • 查看函数日志，确认Scheduler触发时的请求参数是否被函数逻辑误判为无效参数。
  • 暂时简化函数的请求验证逻辑，跳过非必要的头信息检查，测试是否能正常触发。

4. 对比函数部署配置的隐性变更 #

• 检查重部署时是否无意中修改了触发类型或VPC网络配置：
  • 若新函数启用了VPC连接器，而Scheduler未配置访问VPC的权限，会导致请求被拦截。
  • 用gcloud functions describe FUNCTION_NAME命令对比新旧函数的部署配置，重点关注vpcConnector、ingressSettings等字段是否一致。

5. 验证新函数的服务账号权限绑定 #

• 即使使用与旧函数相同的服务账号，新函数可能未正确继承权限：
  • 执行gcloud functions add-iam-policy-binding NEW_FUNCTION_NAME --member=serviceAccount:SCHEDULER_SERVICE_ACCOUNT --role=roles/cloudfunctions.invoker，确保服务账号拥有调用新函数的权限。
  • 检查服务账号是否被添加了组织级别的IAM deny规则，阻止了对新函数的调用。

6. 模拟Scheduler请求定位问题 #

• 生成服务账号的OIDC令牌，用curl模拟Scheduler的请求场景：

  # 生成令牌
  TOKEN=$(gcloud auth print-identity-token --audiences=https://REGION-PROJECT_ID.cloudfunctions.net/NEW_FUNCTION_NAME --impersonate-service-account=SCHEDULER_SERVICE_ACCOUNT)
  # 调用函数
  curl -H "Authorization: Bearer $TOKEN" https://REGION-PROJECT_ID.cloudfunctions.net/NEW_FUNCTION_NAME
  

• 若curl请求也返回INVALID_ARGUMENT，说明问题出在函数端或IAM配置；若curl正常，则需排查Scheduler的特殊配置（如时区、参数编码）。

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