What happens during workflow replay when mutable side effect is recomputed to a different result?

I happened to see mutableSideEffect when I was working with sideEffect in Java SDK. Reading documentations and asking ChatGPT made me confused.

In my understanding, sideEffect gets computed only once and the same result gets reused across workflow replay to maintain determinism.

As for mutableSideEffect, this feature supports recomputation of the effect when the given condition is true. My questions are:

  1. What kind of use cases would require mutableSideEffect?
  2. When a workflow gets replayed at runtime and the mutableSideEffect happens to be recomputed to a new value that is different from the original result, this might cause the workflow to take a new path and produce different events from the ones in Event History. I believe this would cause non-determinism error, meaning the mutable part is not usable at all? Then why do we have this feature?

I’d be very grateful if someone could explain mutableSideEffect to me :smiley:

The use case for mutableSideEffect is reading a configuration value that can change repeatedly. Imagine code like this:

for {
   value = readConfigValue()
    doSomething(value)
}

If readConfigValue uses sideEffect, then a marker event is written for each loop iteration, even if the returned value is the same. When mutableSideEffect is used for this only one marker per different value is recorded.

When a workflow gets replayed at runtime and the mutableSideEffect happens to be recomputed to a new value that is different from the original result,

mutableSideEffect doesn’t recompute value during replay. It uses values recorded in the history, so it is deterministic.

1 Like