数据库触发器是否存在竞争条件？Firebase云函数读取字段偶现非空值为null

你的场景里确实大概率是竞争条件在作祟，这正是你遇到问题的核心原因！

为什么会读到null？ #

当第一个Cloud Function在账户创建时填充字段（包括设置accntActive为true），Firebase数据库的触发器是基于数据变更事件触发的，但这里存在两种典型的竞争场景：

• 分步更新导致中间状态被捕获：如果你的第一个函数是分多次写入用户字段（比如先创建空的用户节点，再逐个添加字段），那么当accntActive字段还未被设置时，若触发器监听的是整个用户节点的变更，就会误触发，此时读取自然是null。
• 数据持久化延迟：即使是一次性写入，Firebase分布式数据库在同步数据时可能存在极短延迟，第二个函数的触发器可能在accntActive的值还未完全持久化到数据库时就被触发，导致读取到旧的null值。

解决办法 #

针对这些问题，你可以尝试以下几种方案：

• 原子性更新用户条目：把所有字段的写入合并成一个原子操作，比如使用update()一次性写入所有需要填充的字段（包括accntActive），而不是分多次调用写入接口。这样触发器只会在所有字段都写入完成后触发，避免中间状态被捕获。
• 精准配置触发器：确保第二个函数的触发器是仅监听accntActive字段的变更，而非整个用户节点的变更。比如在Firebase Functions中，使用onUpdate触发器并指定字段路径，只在该字段发生变化时才触发函数。
• 添加重试与验证逻辑：在第二个函数中，如果读取到accntActive为null，不要直接终止执行，可以添加短暂的延迟（比如几百毫秒）后重新读取，最多重试几次，直到获取到有效值或者超时。
• 替换触发器为显式调用：如果对执行顺序要求严格，可以在第一个函数完成所有字段写入后，直接调用第二个函数的业务逻辑（或者通过Pub/Sub消息来触发），完全绕过数据库触发器的竞争问题，确保第二个函数只在accntActive已经被设置为true后才执行。

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