azure-functionsorchestrationdeterministicnon-deterministic

Is a test in a Durable Azure Orchestrator function non-deterministic if the test could yield a different result on re-run?


This question is about determinism in an Azure orchestrator function that does some updates to a third-party system when an entity changes in the same third-party system.

I am considering using durable Azure functions managed by an orchestrator function with the following design:

A webhook receives the old and new entity versions and fires an orchestrator function. The orchestrator function starts by calling an activity function that returns a bool if some updates are required. The important thing is that the criteria that determine updates call external APIs which may yield different results on a rerun of the orchestrator function.

Is this non-deterministic and cause "non-deterministic workflow detected" errors? Or will it work because I have pushed the tests to an activity function that returns a bool and the logic in the orchestrator function is unchanged?

Put another way, does the determinism constraint in an Azure function block logic in an orchestrator function that may have different paths on a re-run?

Schematic

I have reviewed this Orchestrator function code constraints


Solution

  • A webhook receives the old and new entity versions and fires an orchestrator function. The orchestrator function starts by calling an activity function that returns a bool if some updates are required. The important thing is that the criteria that determine updates call external APIs which may yield different results on a rerun of the orchestrator function.

    Is this non-deterministic and cause "non-deterministic workflow detected" errors? Or will it work because I have pushed the tests to an activity function that returns a bool and the logic in the orchestrator function is unchanged?

    Activity function results are stored in the history table. On replays the activity is not executed again; instead the result is fetched from history table. Of course if you start a new instance of the orchestrator, that will run the activity as no history exists for that instance. The implementation is correct and deterministic.