firebase - Cloud Scheduler 作业命中 HTTPS 端点并记录失败(状态 502)，但服务器返回成功响应(状态 200)

Question

我有一个云调度程序作业，它应该每小时访问我的 API 以更新一些价格。这些作业大约需要 80 秒才能运行。

这是它的作用:

POST https://www.example.com/api/jobs/update-prices

我的应用托管在 Firestore 上，/api/jobs/** 由名为 server-jobs 的云运行服务处理。

firebase.json

{
  "source": "/api/jobs/**",
  "run": { "serviceId": "server-jobs", "region": "europe-west1" }
},

几乎一切正常。查看我的 server-jobs 服务的日志:

您可以看到 Google-Cloud-Scheduler 用户代理。您可以看到所有响应都是 200 OK。

但是在 Cloud Scheduler 控制台上，作业似乎失败了:

查看云调度程序日志:

它记录了以下错误:

Status 502 "type.googleapis.com/google.cloud.scheduler.logging.AttemptFinished"

但是那个 502 根本不是来 self 的服务器。

更多详情

我有 2 个不同的自定义域连接到该 Firebase 托管。而且该错误仅发生在其中一个域中。我有两个云调度程序作业(配置完全相同)到每个连接的域。

JOB 1 https://www.example1.com/api/jobs/update-prices SUCCEEDS (job takes ~35 seconds)
JOB 2 https://www.example2.com/api/jobs/update-prices FAILS (job takes ~80 seconds)

我认为工作时长与此无关。因为一开始，我运行的是完全相同的作业，但直接点击 Cloud Run URL(不通过 Firebase 托管代理)并且它被记录为成功。此错误仅在我开始访问连接的 Firebase 托管域而不是直接访问云 URL 服务 URL 时才出现。

这些域名在不同的地方和不同的国家注册。但两者都已正确配置并且在生产中运行良好。

而且我的服务器每次登录都是成功200。

更新

我刚刚注意到一个模式:

似乎错误是在作业启动后恰好 1 分钟(60 秒)触发的。所以工作的持续时间可能与它有关。因为需要 80 秒的工作是“失败”，而另一个需要 35 秒的工作是成功的。这是超时问题吗？什么返回 502？因为我的服务器正在按预期工作，正如您从日志中看到的那样。

更新 2

我刚刚使用 gcloud scheduler jobs descript JOB_NAME 检查了作业，并且它们都配置了 attemptDeadline: 180s。所以我的工作持续时间应该不是问题，因为它们都在 180 秒以下。

更新 3

正如我所怀疑的，工作期限似乎是这里的问题。

我已经对我的 API 处理程序函数进行了以下测试:

• 等待 59 秒，然后 res.sendStatus(200)
• RESULT:Cloud Scheduler 将两个作业显示为 SUCCESS

还有:

• 等待 65 秒，然后 res.sendStatus(200)
• 结果:Cloud Scheduler 将两个作业显示为失败

似乎链上有一个 60 秒的阈值:

• 云调度器
• Firebase 托管
• 云端运行

Answer 1

我猜 Firebase 托管是这里的罪魁祸首。

Firebase 托管有一个默认的 60 秒请求超时。这就是作业即使在服务器上成功时也会看到错误的原因。

发件人:https://firebase.google.com/docs/hosting/functions

Note: Firebase Hosting is subject to a 60-second request timeout. Even if you configure your HTTPS function with a longer request timeout, you'll still receive an HTTPS status code 504 (request timeout) if your function requires more than 60 seconds to run. To support dynamic content that requires longer compute time, consider using an App Engine flexible environment.