Durable Azure Orchestrator 功能中的测试是否具有不确定性（如果测试在重新运行时可能产生不同的结果）？

Question

这个问题是关于 Azure 协调器功能中的确定性，当同一第三方系统中的实体发生更改时，该功能会对第三方系统进行一些更新。

我正在考虑使用由具有以下设计的协调器功能管理的持久Azure功能：

Webhook 接收新旧实体版本并触发协调器功能。 Orchestrator 函数首先调用一个活动函数，如果需要某些更新，该函数将返回 bool。重要的是，确定更新的标准调用外部 API，这可能会在重新运行协调器功能时产生不同的结果。

这是否是非确定性的并导致“检测到非确定性工作流程”错误？或者它会起作用吗，因为我已将测试推送到返回 bool 的活动函数，并且协调器函数中的逻辑没有改变？

换句话说，Azure 功能中的确定性约束是否会阻止协调器功能中的逻辑，而该功能在重新运行时可能具有不同的路径？

我已经审查了这个Orchestrator功能代码约束

Answer 1

Webhook 接收新旧实体版本并触发 协调器功能。 Orchestrator 函数首先调用 如果需要某些更新，则返回 bool 的活动函数。 重要的是确定更新的标准调用 外部 API 可能会在重新运行时产生不同的结果 协调器功能。

这是否是非确定性的并导致“非确定性工作流程” 检测到“错误？或者它会起作用，因为我已经将测试推送到 返回 bool 的活动函数以及其中的逻辑 Orchestrator 功能不变？

活动函数结果存储在历史表中。 重播时，活动不会再次执行；相反，结果是从历史表中获取的。 当然，如果您启动编排器的新实例，则会运行该活动，因为该实例不存在历史记录。 实现是正确且确定的。