我的问题是关于函数的cosmosDB触发器。我们正在探索触发我们功能的最佳方式。我们最初的想法是通过将消息推送到服务总线并从服务总线触发器实例化函数来触发它。我们知道，当我们通过服务总线或队列触发一个函数时，如果函数执行由于任何原因失败，消息将在锁定期到期后返回队列。这符合我们的用例，但是高级服务总线相当昂贵(600美元/小时)。
我想知道当我们有一个CosmosDB触发器时会发生什么?在这种情况下，如果函数失败(比如在未处理的异常期间)，触发器是否丢失，或者是否有某种方法来管理重新触发器?我们如何管理重试和失败场景?
Cosmos DB的Azure Functions触发器在内部使用Change Feed Processor Library。关于其错误处理状态的文档:
防止您的更改提要处理器"卡住";不断地重新尝试同一批更改，您应该添加逻辑在您的委托代码中编写文档，在例外情况下，为死信队列。这种设计确保您可以跟踪未处理的更改，同时仍能继续处理未来的变化。死信队列可能是另一个Cosmos容器。确切的数据存储并不重要，只需未处理的更改将被持久化。
结论是，Change Feed本身不会保留任何关于处理错误的状态——这取决于作为消费者的您。更好的模式是将其与Service Bus之类的队列配对，后者为可靠的错误处理提供死信处理。一种模式是有一个专门的函数来读取Cosmos更改提要(使用Cosmos触发器)，它只需将感兴趣的事件插入队列中，以触发其他函数进行可靠的处理。
当Change Feed Trigger使用下面的Change Feed Processor时，错误处理是不同的。
对于未处理的异常，Change Feed Processor将再次重试同一批文档。
另一方面，Change Feed Trigger(类似于Event Hub等其他触发器)继续处理未处理的异常(参考https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-changefeed-functions#some-changes-are-missing-in-my-trigger)。理想情况下，从代码的角度来看，确保有参考中推荐的try/catch块来处理任何失败场景。通常，失败的文档可以发送到队列或日志接收器以供稍后分析。如果发送到死信队列，则可以使用QueueTrigger重试，或者根据故障的性质使用任何其他机制。
我认为这是一个标准，它不会重试，但目前有一个重试策略的预览功能，可以用于所有触发器和语言。
e。将此添加到function.json
"retry": {
"strategy": "fixedDelay",
"maxRetryCount": 3,
"delayInterval": "00:00:05"
}
对于c#，添加以下属性
[FixedDelayRetry(3, "00:00:05")]
更多配置信息:https://learn.microsoft.com/sv-se/azure/azure-functions/functions-bindings-error-pages?tabs=csharp#retry-policies-preview