0

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

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thank you! On a replay would the activity function bottom right that "makes update" run again based on the result of the evaluate changes replay pulled from history? Does that need to be idempotent?
Activities are only run once when everything goes fine. If something goes wrong internally in Durable Functions, it is possible for an activity to run more than once though. Idempotency is usually a good property.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.