问题标签 [cosmosdbtrigger]

我的问题是关于函数的 cosmosDB 触发器。我们正在探索触发我们功能的最佳方式。我们最初的想法是通过将消息推送到服务总线来触发它，并让函数从服务总线触发器中实例化。我们知道，当我们通过服务总线或队列触发一个函数时，如果函数执行由于某种原因失败，消息会在锁定期到期后返回队列中。这适合我们的用例，但高级服务巴士相当昂贵（600 美元 pm）。

我想知道当我们使用 CosmosDB 触发器时会发生什么？在这种情况下，如果函数失败（假设在未处理的异常期间），触发器是否丢失或者是否有某种方法来管理重新触发？我们如何管理重试和失败场景？

我正在尝试在我的预编译 C# CI/CD 部署项目中创建一个 CosmosDBTriggered 函数。

这是功能实现，它被部署而没有任何抱怨。我尝试过静态和实例方法。

监控/洞察工具报告没有错误，也没有调用，即使监视的集合在部署时有项目和更改。

该函数表示它已启用并具有 Cosmosdb 触发器：

我尝试单独添加这些依赖项，但没有更改：

如我所料，此函数不会出现在任何 CosmosDB 集合的触发器中，但我认为这可能是针对不同类型的触发器。

我缺少什么配置步骤？

更新

当我注释掉这个 [CosmosDB] DocumentClient 绑定（以及任何依赖它的东西）时，就会调用该函数。所以我想这是一起使用这些绑定的问题吗？

我正在编写一个 Cosmos DB 后触发器（不是 Azure 函数触发器类型，而是服务器内 JS 触发器）。在这个触发器中，我需要访问响应中生成的etag标头。触发器工作正常，除非我添加以下代码：

此代码导致请求失败，并出现以下异常：“无法在 getValueInternal 处获取未定义或空引用的属性‘值’ ”。我检查了响应不是null并且该getValue函数存在，实际上异常是从getValue函数内部抛出的，因为etag的属性不存在。

然而，文档（在此处找到）指出：

getValue(key) → {string} 获取指定的响应头值。

其他文档（在此处找到）也指出：

以下响应标头对于来自 SQL API 的所有响应都是通用的： ... etag（etag 标头 [...] 与响应正文中的 _etag 属性具有相同的值。）...

现在我还确认我确实可以从 访问etag，__.response.getBody()但我不能依赖该选项，因为我的请求是使用EnableContentResponseOnWrite = false选项发出的，在这种情况下，响应正文为空。

有人可以帮我弄清楚我在这里遗漏了什么或做错了什么吗？

我在 ac# 类库项目中有一个函数，该函数由 cosmos 数据库中的更改触发：

我能够弄清楚如何从 settings.json （databaseName, collectionName, 等...）中提取一些值，但不是FeedPollDelayor MaxItemsPerInvocation（由于它们是 type int）。

我知道生成了一个 function.json，但我不知道如何修改它（而且 MSDN 似乎暗示你不应该这样做）。

我有一个容器，我听它的变化。根据我从更改提要中收到的文档类型，我会在为我的阅读量大的应用程序填充或更新我的物化视图容器时以不同的方式处理每个文档。

在最新的扩展 v4.x 中，来自更改提要的文档传递到 a 中的函数IReadOnly<T>不再将 Document 作为 T 并且需要具体类型。

System.string传递 'dynamic' 会引发 'can not cast '异常，System.IReadOnly<System.object>这显然表明函数接收 JSON 集合并将其反序列化为 T 的集合。

目前，作为一种解决方法，在我的本地开发环境中，我为集合中的每种类型创建了一个函数，并根据需要对其进行处理。

这种方法的缺点是它在生产中会很昂贵，因为每次更新都会调用所有函数。吃光我的功能调用配额。因此，将调用 10 个函数而不是单个函数调用，其中 9 个函数完全什么都不做，只是检查它们是否必须做任何事情然后返回。

我的类型都共享一个基类，该基类具有四个属性（id、pk、ttl 和标签（这是我用来区分我的类型的区分属性）。但是使用此基类型作为 T inIReadOnly<T>不是一种选择同样，因为在反序列化之后，除了它定义的四个属性之外，所有其他属性都将丢失。

我们已经实现了一个包含多个 Azure Functions 的服务。HttpTrigger 函数会将记录插入 Cosmos DB。然后 Cosmos DB 触发器函数将在触发时处理记录。有时 DB 触发器功能的工作可能需要相当长的时间。如果在 DB Trigger 函数与先前作业一起运行时将新记录插入 Cosmos DB，则新记录不会导致事件被触发。

我们如何才能防止这种情况发生？谢谢！

我正在尝试使用 cosmos db changefeed 在 cosmos db 中的更改上触发 azure 函数。我正在尝试使用可用的重试策略触发“至少一次”功能：https ://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-error-pages?tabs =csharp

所以，我有一个由 CosmosDbTrigger 触发的天蓝色函数，它没有内置的弹性。我已经在这个天蓝色函数上声明了一个无限重试策略来解决这个问题。如果函数因任何原因失败，重试策略会按预期工作，并且函数会在固定延迟后重新运行。只要函数不返回成功结果，我还可以验证我在 cosmosdb 中的租约项不会更新。但是，一旦我停止我的天蓝色函数并重新启动它，该函数就不再重试。租约已更新，我对此的唯一解释是 cosmos db 中的检查点已提前。（如果我在 Visual Studio 中本地停止应用程序，通过禁用 azure 中的功能或重新部署 azure 中的功能，行为是相同的）

我的理解是，检查点应该只在 azure 函数的成功结果上被推进，但是当函数应用程序在重试运行之间停止时，它似乎也被推进。这使我无法保证我的功能至少执行一次。

有人可以尝试向我解释一下，为什么重启后没有重试该功能？