英文:
Should firestore triggers be idempotent when there is no retry?
问题
Firestore触发器是否需要幂等性尚不清楚，至少在所有情况下是否需要。
文档提到，在出现错误重试的情况下，函数需要具备幂等性，这是一个可选择的功能。如果有人没有选择使用重试功能，那么不清楚函数是否需要具备幂等性。
我了解评论中发布的其他帖子，但它们与Firebase文档不符。具体来说：
> 即使被多次调用，您的函数应该产生相同的结果。这使您可以在先前的调用在代码执行过程中部分失败的情况下重试调用。有关更多信息，请参阅重试事件驱动函数。
重试功能是一个可选择的功能，因此如果您没有选择使用重试功能，函数是否需要具备幂等性呢？换句话说，如果您没有选择使用重试功能，函数是否可以多次接收相同的事件？
这一信息非常重要，因为幂等性可能会使某些用例变得复杂。因此，如果不需要幂等性，您可能不希望考虑这一点。
英文:
It is not clear whether firestore triggers need to be idempotent, at least if they should be in all cases.
The doc mentions that the function needs to be idempotent in case of error retries which are opt in. In case someone did not opt-in, it is unclear whether a function needs to be idempotent.
I'm aware of the other post posted in comments, but they are at odds with firebase doc. Specifically:
> Your functions should produce the same result even if they are called multiple times. This lets you retry an invocation if the previous invocation fails partway through your code. For more information, see retrying event-driven functions.
That retry feature is an opt-in feature, therefor if you did not opt-in, does the function need to be idempotent ? Put it another way, if you did not opt-in for retries, can a function receive the same event twice
This piece of information is vital as idempotency can complexify some use cases. So you wouldn't want to take it into account if it does not have to be.
答案1
得分: 2
如果您没有选择重试，一个函数是否可以收到相同的事件？
是的，可以。您必须假设Cloud Functions事件生成器与您的函数代码之间的通信渠道是异步的，不是100%可靠的（正如计算机系统通常是的）。不能保证一个事件确实会传递给您的函数。如果一个事件丢失了（因为您的函数没有接收到它并以某种方式确认接收），则该事件将被重复发送，直到您的函数运行并向事件生成器报告事件已处理（或者超出一定的重试次数）。
这些重试类型与您的函数在事件处理上明确失败时选择的重试不同。失败是对事件的一种确认方式。当您选择为失败启用重试时，那是针对您的函数代码中的失败，而不是一般系统中的失败。
至于您的函数是否需要实现幂等性，完全取决于您，尽管如此。也许如果事件被处理两次对您来说不是个大问题，但我们无法告诉您是否是这种情况。您必须为您的项目定义这个要求。
英文:
> if you did not opt-in for retries, can a function receive the same event twice
Yes, it can. You have to assume that the communication channel between the Cloud Functions event producers and your function code is asynchronous and is not 100% reliable (as computer systems often are). There is no guarantee that an event that is meant for your function will actually end up in your function. If an event is lost (because your function didn't receive it and acknowledge its receipt somehow), the event will be sent again, repeatedly, until your function runs and reports back to the event producer that the event was handled (or some max number of retries is exceeded).
These types of retries are different than the ones you opt into when your function explicitly fails on the processing of an event. A failure is a form of acknowledgement of the event. When you opt into retries for failure, that's for failures in your function code, not the system in general.
Whether or not your function needs to implement idempotency is entirely up to you, though. Maybe it's not a big problem for you if the event gets processed twice, but we can't tell you if that's the case. You have to define that requirement for your project.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论