Is evaluation of the unblocking condition for Workflow::await cached similarly to outputs of Activities?
It is key to understand to decide whether workflow members modified by signals can be modified in several places of the workflow and accessed from several places in unblocking conditions for await.
I expect to get a positive answer here because not caching it could cause behaviour that would not be same at each replay and would not be deterministic in case a signal would be received between replays.
Is evaluation of the unblocking condition for Workflow::await cached similarly to outputs of Activities?
I’m not sure what do you mean by “cached”. Output of activities is not cached, but stored as part of the workflow execution history.
It is key to understand to decide whether workflow members modified by signals can be modified in several places of the workflow and accessed from several places in unblocking conditions for await.
Yes, workflow members can be modified from any workflow code and can be used in any await statement in the workflow code.
I expect to get a positive answer here because not caching it could cause behaviour that would not be same at each replay and would not be deterministic in case a signal would be received between replays.
Temporal uses replay to reconstruct workflow state. Caching is not used.
Please replace “cached” by “stored” in my question, that is what I meant.
When reconstructing the workflow state, some code will be re-executed (workflow) but some will be skipped (activities) with previously stored outputs being reused. That’s clear. The question is if the unblocking condition in await is re-executed during replay or it’s output is reused because it was saved during the first execution.
An example use case is:
In a first activity call an external service with an asynchronous response pattern
Call await with a condition that the response was received
In a second activity process the response and finalise
Implement a signal method that receives the asynchronous response which will unblock the await in step 2
In case step 4 fails: step 1 is not executed again, so question is whether step 2 will hang for ever or not.
This is probably a wrong example because the signal method call will also be stored and re-executed. Maybe there cannot exist any example where re-executing the unblocking condition is an issue. I expected you as team having had a lot of brainstorming on that so you probably can easier state whether re-executing the unblocking condition during replay could have unexpected behaviour.
Signals and their values are recorded in workflow history. On workflow replay the recorded signals would trigger your signal handler and unblock the await condition. If you remove the signal handler from your workflow code between worker restarts the conditions would not get unblocked and you could run into non-deterministic errors as well based on your workflow history and the changed workflow code.
Thanks a lot for this clarification. That brings another question in my mind: how the platform handles events in the history that cannot be applied. One of them is a missing signal handler. But a second one that comes to my mind is activity call that will be removed. Does the platform silently skip those events during replay?
Workflow code has to be deterministic. To make changes in your workflow code (for long-running workflow for example), take a look at workflow versioning (docs, video).
Removing an activity invocation (that was already executed) without versioning would result in non-deterministic errors that would block your workflow execution.
You can test if changes in your workflow would result in non-deterministic errors by using WorkflowReplayer, which SDK are you using?