Firestore事务重试行为与文档限制不符，空闲时间定义存疑

官方定义与核心疑问 #

事务会在270秒后过期，或空闲60秒后过期

这里的**“空闲”并非指本地CPU空闲**，而是指事务与Firestore服务端之间无读写交互的间隔时长——即从上次向服务端发起读写操作，到下一次发起操作的这段时间，不管本地在执行CPU计算还是其他无IO操作，只要没有和服务端交互，就会被判定为事务空闲。

用户测试案例 #

用户通过Node.js API测试得到以下结果：

• 当事务内读写操作间的同步CPU计算耗时超过120秒时，即使总耗时小于270秒，事务也会不断重试直至失败：

(transaction) {
   transaction read operation
   // 120秒的本地哈希计算等无IO操作
   transaction write operation
}    

• 当该计算耗时小于120秒时，事务无需重试即可成功：

(transaction) {
   transaction read operation
   // 110秒的本地哈希计算等无IO操作
   transaction write operation
}    

原因解析 #

测试中出现120秒阈值而非文档标注的60秒，核心原因是Firestore Node.js客户端内置了事务自动重试机制：

1. 首次触发60秒空闲超时后，客户端会自动重试整个事务流程；
2. 重试后的事务再次进入本地计算阶段，若计算仍耗时接近60秒，第二次空闲超时触发时，重试次数耗尽或事务上下文已失效，最终导致事务失败；
3. 两次超时窗口叠加，就形成了实际测试中约120秒的失败阈值。

优化建议 #

事务的设计目标是短时间内完成的原子读写操作，长时间的本地计算逻辑应该从事务回调中剥离：

• 先在事务外部完成所有本地计算；
• 再启动事务，快速执行读写操作，避免触发空闲超时。

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