Javascript Firebase Web事务应用程序不抑制初始本地事件

因此，自从我开始在Firebase Cloud Functions环境中使用Firebase Web事务以来，我一直无法让第三个参数“ApplyLogic”正常工作。我一直将其设置为false，以禁止获取初始null值，因为从事务中获取的数据本身实际上是null。当我在部署代码后运行代码时，它会将null传递给update函数，但是当我再次运行代码而没有新的部署到云函数时，它会抑制所有本地事件，并且我只看到我的数据

Q：事务参数“ApplyLocal”设置为false时，是否应该在每次ApplyLocal设置为false时抑制本地缓存的值，或者它的构建是为了在初始代码部署后，将null作为传递给更新函数的值？

我问这个问题的原因是，如果本地缓存的值不是每次都被抑制，那么我就必须考虑初始的中间状态，而我根本不理解为什么我应该在应用上使用它。也因为我没有看到文档中有任何详细说明

我读过的文件有：

我也遇到过一个类似的问题，答案似乎很准确，但是 这个问题和答案已经有4年多的历史了（不确定是否过时），并且指向旧文档的链接没有提供当前文档所没有的任何内容

以下是在我的环境中复制此错误的代码：

workerDataRef.transaction(firstTransactionUpdater,firstTransactionOnComplete,false);
  function firstTransactionUpdater(workerData){
    console.log(`Transaction checker Function Running. Worker Data is `,workerData);
    if(workerData === null){ //data should not be null
      console.log("100 Data was null");
      return workerData;
    }
    else{ //workerData is not null
      //DO WORK
      console.log("200 Data was not null");
      return workerData;
    }
  }
  function firstTransactionOnComplete(error, committed, snapshot) {
    if (error) { //error thrown
      throw new Error(error);
    } else if (!committed) { //transaction aborted
      console.log(`Transaction checker aborted!`);
    } else { //transaction completed successfully
      console.log("Continuing on with next process");
    }
  }

以下是此代码块在部署到云函数后运行两次后生成的日志：

1:35:40.495 PM Function execution took 410 ms, finished with status: ok 
1:35:40.494 PM Continuing on with next process  
1:35:40.489 PM 200 Data was not null  
1:35:40.489 PM Transaction checker 2 Function Running. Worker Data is {    
//... } 
1:35:40.400 PM 100 Data was null  
1:35:40.399 PM Transaction checker 2 Function Running. Worker Data is null  
1:35:40.190 PM Function execution started  

1:34:35.386 PM Continuing on with next process  
1:34:33.985 PM 200 Data was not null  
1:34:33.885 PM Transaction checker 1 Function Running. Worker Data is { //.. 
}
1:34:25.698 PM Function execution took 623 ms, finished with status: ok 
1:34:25.504 PM 100 Data was null  
1:34:25.499 PM Transaction checker 1 Function Running. Worker Data is null  
1:34:25.076 PM Function execution started  

更新

*在运行和尝试复制事件数据时，只有在初始部署之后才发现事件数据为null，这是错误的。本地缓存的数据只是在不一致的时间以null形式传递。在“ApplyLocaly”设置为false的单个部署之后多次运行事务仍然会传递null，有时不会

事务参数“ApplyLocal”设置为false是否应该抑制本地缓存的值

不，这不是

参数的用途。专家们说得最好：

默认情况下，每次运行事务更新功能时都会引发事件。因此，如果多次运行，您可能会看到中间状态。您可以将其设置为false以抑制这些中间状态，并在引发事件之前等待事务完成

将
applyloly
设置为
false
不会从根本上改变在线交易的行为。它仅在客户端/SDK引发事件时更改

默认情况下，客户机会尽快引发事件，然后在需要时引发对账事件。当您将
applyloly
设置为
false
时，客户端只有在收到服务器确认其数据已提交后才会引发事件

有关事务如何运行的说明，请参见。默认行为是Firebase客户端将在步骤2之后引发事件，这可能会发生多次。将
applyloly
设置为
false
将导致仅在服务器确认写入值后，在步骤4之后引发事件

事务参数“ApplyLocal”设置为false是否应该抑制本地缓存的值

不，这不是
参数的用途。专家们说得最好：

默认情况下，每次运行事务更新功能时都会引发事件。因此，如果多次运行，您可能会看到中间状态。您可以将其设置为false以抑制这些中间状态，并在引发事件之前等待事务完成

将
applyloly
设置为
false
不会从根本上改变在线交易的行为。它仅在客户端/SDK引发事件时更改

默认情况下，客户机会尽快引发事件，然后在需要时引发对账事件。当您将
applyloly
设置为
false
时，客户端只有在收到服务器确认其数据已提交后才会引发事件

有关事务如何运行的说明，请参见。默认行为是Firebase客户端将在步骤2之后引发事件，这可能会发生多次。将
applyloly
设置为
false
会导致事件仅在服务器确认写入值后的第4步后才会引发。
由于您编写的代码有问题，请共享再现该问题的最小代码。@FrankvanPuffelen好的，代码已添加，并检查代码是否再现了我的问题。Firebase实时数据库事务的内部工作方式自引入以来没有改变。因此，以前的答案不太可能完全无效。由于您编写的代码有问题，请共享再现该问题的最小代码。@FrankvanPuffelen好的，代码已添加，并检查代码是否再现了我的问题。Firebase实时数据库事务的内部工作方式自引入以来没有改变。所以之前的答案不太可能完全无效，所以本质上，当我编写更新函数时，我应该总是期望通过更新函数传递null的可能性？我希望ApplyLogic在第一次回调得到实际数据而不是猜测之前不会调用它，但听起来ApplyLogic会影响正在运行的第二次回调，并在事务中止或数据写入之前阻止它运行。是吗？您应该随时准备接收
null
作为当前值