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

versioning & patching

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

WorkerDeploymentVersion is required for Serverless Workers

The WorkerDeploymentVersion is required when using TemporalLambdaWorker.CreateHandler. Worker Deployment Versioning is always enabled for Serverless Workers.

Versioning behavior requirement for Lambda workflows

Each Workflow must have a versioning behavior, either AutoUpgrade or Pinned. Set it per-Workflow with the [Workflow] attribute, or set a worker-level default with DefaultVersioningBehavior in DeploymentOptions. The default versioning behavior is AutoUpgrade.

Continue-As-New for indefinite Entity Workflow execution

Continue-As-New allows an Entity Workflow to run for years without unbounded history. When workflow.info().is_continue_as_new_suggested() returns True, the history is approaching the suggested threshold (~4,096 Events). The Workflow should serialize current state, drain pending work, wait for all handlers to finish, then call workflow.continue_as_new() with the current state. The new Execution receives the same Workflow Id, a new Run Id, and a fresh Event History.

Worker Versioning behavior for Entity Workflows

For Entity Workflows, use PINNED versioning behavior: each execution runs entirely on the Worker Deployment Version where it started. At a Continue-As-New boundary the Workflow can optionally upgrade to the latest build. This ensures long-lived entities are not patched mid-execution, avoiding nondeterminism errors.

Continue-As-New transition steps

The Continue-As-New transition in three steps: unprocessed Signals are preserved by serializing them into pending_events on the state for restoration in the next Execution; all handlers complete via workflow.all_handlers_finished() to ensure in-flight Update handlers finish before transition; the transition occurs via workflow.continue_as_new(self._state) which ends the current Execution and starts a new one with the same Workflow Id, new Run Id, and fresh Event History.

Carrying unprocessed signals through Continue-As-New

Unprocessed Signals are serialized into pending_events on LoyaltyState before Continue-As-New. Limit the number of pending signals carried (e.g., MAX_PENDING_CARRY=500) to keep the state payload well under the 2 MB limit. Drain excess signals before serializing.

Python SDK @workflow.defn versioning behavior parameter

Add versioning_behavior=VersioningBehavior.PINNED to @workflow.defn for Entity Workflows using Worker Versioning. This ensures each execution completes entirely on the version where it started.

Worker deployment configuration for versioning

Configure Worker with WorkerDeploymentOptions including deployment_name, build_id matching across all Workers from the same build, and use_worker_versioning=True. BUILD_ID should be injected by CI/CD (e.g., Git SHA).

Checking for Worker version upgrade at Continue-As-New boundary

In the Continue-As-New method, check workflow.info().get_target_worker_deployment_version_changed(). If True, a newer build is available. Include ContinueAsNewVersioningBehavior.AutoUpgrade in options to upgrade on the CaN boundary. This flag is refreshed after each Workflow Task.

Draining old Worker versions after deployment

After deploying a new build and promoting it to Current, old Workers keep running and drain their pinned Executions automatically. Check drain status with 'temporal worker deployment describe-version' — when DrainageStatus shows 'drained', old Workers are safe to shut down.

Workflow.all_handlers_finished() before Continue-As-New

Call await workflow.all_handlers_finished() before Continue-As-New to ensure any in-flight Update or Signal handlers complete. Cancelling them mid-execution would lose data. This is part of the graceful transition.

WorkflowExecutionOptionsUpdated event indicates options updated

WorkflowExecutionOptionsUpdated event indicates that Workflow options have been updated. It has fields: versioning_override (Versioning override upserted in this event, ignored if nil or if unset_versioning_override is true), unset_versioning_override (Versioning override removed in this event), attached_request_id (Request ID attached to running workflow execution for deduping subsequent requests with same ID), attached_completion_callbacks (Completion callbacks attached to running workflow execution).

Non-determinism error recovery method

If errors started after a deploy and aren't going away, roll the Worker back. Affected Executions pick up again on their next Workflow Task retry once compatible code is running. Then add a proper versioning guard before redeploying.

Rolling deploy Non-determinism error transient recovery

During a rolling restart with old and new Worker versions briefly running together, some Executions may fail with Non-determinism errors transiently and recover once the rollout completes.

Give your agent this brain