Why can't Workflows contain non deterministic code? And how does using activity solve the problem?


  1. What is the technical constraint in temporal that prevents worklfows from containing non determinitic code?
  2. How does wrapping non deterministic code as an activity and invoking the activity from workflow overcome the constraint?
  1. To recover workflow state the workflow function is reexecuted from the beginning. All Temporal APIs return recorded responses which are exactly the same as the original ones. If the workflow code is non deterministic then it can end up in a different state than the original execution.

For example, the original execution of the workflow can execute activity A. But during replay, it might execute activity B which is not going to match the execution history.

if (random() > 0.5) {
} else {
  1. Activity result is recorded in the workflow execution history. So during recovery the result is taken from the history without executing the activity.

Thanks Maxim.

In the below video, It says “In case of a failure, Temporal resumes the workflow to the exact line it was running before the crash.”

Isn’t what she told more conceptual than practical?
Because temporal deosn’t really store the line number where it crashed and directly resume from the point of failure?
Instead as you said it re-executes everything (pulling temporal api’s recorded responses)?

Is it right to say what is said in this video is conceptually correct but that’s not really the way it happens behind the scenes?

It’s conceptually correct, yes. Event history replay brings your workflow state to the exact point where the failure happened and can continue its execution. From the developer point of view, it can be considered “the exact line of code before the crash”, in most cases.

For example if you have a for loop that just adds 10 numbers , and your service crashes during the for loop, then during replay that for loop will be replayed from the beginning.
In case you have a for loop where inside you do operations such as invoking activities, workflow.sleep, etc, operations which write to the workflow event history, then yes, after a crash while you are in the loop it will be restored from the exact point where it stopped before.

The cool thing is the resume works across programming languages, as we have shown in our recent workshop demo - temporal-java-workshop/README.md at main · tsurdilo/temporal-java-workshop · GitHub. In the demo we have shown how a workflow that was started in PHP and failed during a for loop execution can be resumed by a Java workflow. Hope this helps

1 Like

Thanks @tihomir.

Side Question
When we invoke query method on a completed workflow, are the same steps followed?
Event History is replayed to reach the completion state and then the query metod is executed?

Yes, the event history is replayed, setting the workflow state to the exact point when the query is evaluated. In case of closed workflows, it’s the entire workflow history.

1 Like