new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Temporal · all subjects

workflow determinism

6 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Runtime checks for incompatible Workflow changes

The Temporal Go SDK performs runtime checks that trigger a nondeterminism error if you add, remove, or reorder any of the following without Versioning: workflow.ExecuteActivity(), workflow.ExecuteChildWorkflow(), workflow.NewTimer(), workflow.RequestCancelWorkflow(), workflow.SideEffect(), workflow.SignalExternalWorkflow(), and workflow.Sleep().

Runtime check limitations

The Go SDK runtime check does not perform thorough validation. For example, it does not check Activity input arguments or Timer duration. Each Temporal SDK implements sanity checks differently, and they are not complete checks for non-deterministic changes. Replay Testing should be incorporated when making Workflow revisions.

Why Workflow Determinism requires versioning

Temporal requires Workflow code to be deterministic. If you make a change to Workflow code that would cause non-deterministic behavior on Replay, you must use a Versioning method to gracefully update running Workflows. This requirement applies only to Workflow orchestration logic; non-deterministic work like API calls and database queries should be placed in Activities.

Activity publishing avoids Workflow state pollution

When events originate in an Activity, publish from the Activity directly rather than returning them for the Workflow to forward. The Workflow hosts the stream but does not read its own stream; it processes the Activity's return value and emits its own lifecycle events. This keeps Workflow state independent of streamed output, which allows retried Activity attempts to surface to subscribers without polluting the Workflow's durable state.

Why dependencies should not be injected into Workflows

Passing dependencies directly into Workflow code breaks Temporal's determinism guarantees, because dependency state can change between replays. Workflow code must remain deterministic. If a Workflow needs configuration, retrieve it through a Local Activity so the value gets recorded in the Event History.

Activity dependency injection pitfall: injecting into Workflows

Injecting dependencies into Workflows breaks determinism because dependency state can change between the original execution and a replay. The Temporal Java SDK documentation explicitly warns against this.

Give your agent this brain