Firestore 事务重试行为与限制不匹配

Question

根据 https://firebase.google.com/docs/firestore/quotas 和 https://cloud.google.com/datastore/docs/concepts/transactions#datastore-datastore-transactional-update 中的 firestore 文档-nodejs

“交易将在 270 秒后或闲置 60 秒后过期。”

这里的“空闲”是什么？ 中央处理器？ 或者这是否引用了通过事务读/写与 firestore 交互之间的最大时间？ 我在这里看到的行为与文档根本不符。

具体来说，

使用 Node.js api，当我运行总时间少于 270 秒但具有长同步 CPU 活动块（无 IO）且事务读/写操作之间总时间超过 120 秒的事务时，事务会重试直至失败。 当长块同步CPU活动所花费的时间为<120s, the transaction does not retry and succeeds immediately.

具体来说，任何交易如：

(transaction) {
   transaction read operation
   120s of calculating a hash or whatever
   transaction write operation
}    

<270s total time

重试直到失败，而任何事务如：

(transaction) {
   transaction read operation
   110s of calculating a hash or whatever
   transaction write operation
}    

<270s total time

无需重试即可成功。

发生什么事了？ 空闲时间限制实际上是 120 秒并按 w.r.t 计算。 Firestore 事务交互？

Answer 1

我联系了他们的支持团队，他们的回应是：

1. IDLE 是通过读/写与 firestore API 进行交互，而不是 CPU 空闲
2. 不要有“其他任务与事务一起运行并阻止它们完成工作”——我猜这意味着除了 firestore API 调用之外的任何其他任务，因为在 firestore API 之间执行单个同步函数调用时会复制此行为互动。

所以基本上，如果您想对文档执行原子读+修改+写操作，其中“修改”操作在 CPU 上运行的时间超过 60 秒，Firestore 将神秘地重试您的事务，直到失败。

他们没有评论交互之间的实际时间限制，从 60 秒到大约 120 秒不等，具体取决于交易中 Firestore 交互的数量，但这就是我所看到的行为。

鉴于原子读取+修改+写入是一种非常常见的模式，我对他们关于这种行为的文档的缺乏感到非常惊讶。 我想这只是另一把 Firestore 步枪 ́_(ツ)_/́