The Temporal Python SDK enables you to run Workflow code in a sandbox environment to help prevent non-determinism errors in your application. The Temporal Workflow Sandbox for Python is not completely isolated, and some libraries can internally mutate state, which can result in breaking determinism.
Benefits
Temporal's Python SDK uses a sandbox environment for Workflow runs to make developing Workflow code safer.
If a Workflow Execution performs a non-deterministic event, an exception is thrown, which results in failing the Task Worker. The Workflow will not progress until the code is fixed.
The Temporal Python sandbox offers a mechanism to pass through modules from outside the sandbox. By default, this includes all standard library modules and Temporal modules. For performance and behavior reasons, users are encouraged to pass through all third-party modules whose calls will be deterministic. For more information, see Passthrough modules.
How it works
The Sandbox environment consists of two main components.
Global state isolation
The first component of the Sandbox is a global state isolation.
Global state isolation uses exec to compile and evaluate statements.
Upon the start of a Workflow, the file in which the Workflow is defined is imported into a newly created sandbox.
If a module is imported by the file, a known set, which includes all of Python's standard library, is passed through from outside the sandbox.
These modules are expected to be free of side effects and have their non-deterministic aspects restricted.
For a full list of modules imported, see Customize the Sandbox.
Restrictions
Restrictions prevent known non-deterministic library calls. This is achieved by using proxy objects on modules wrapped around the custom importer set in the sandbox.
Restrictions apply at both the Workflow import level and the Workflow run time.
A default set of restrictions that prevents most dangerous standard library calls.
Skip Workflow Sandboxing
The following techniques aren't recommended, but they allow you to avoid, skip, or break through the sandbox environment.
Skipping Workflow Sandboxing results in a lack of determinism checks. Using the Workflow Sandboxing environment helps to preventing non-determinism errors but doesn't completely negate the risk.
Skip Sandboxing for a block of code
To skip a sandbox environment for a specific block of code in a Workflow, use sandbox_unrestricted(). The Workflow will run without sandbox restrictions.
with temporalio.workflow.unsafe.sandbox_unrestricted():
# Your code
Skip Sandboxing for an entire Workflow
To skip a sandbox environment for a Workflow, set the sandboxed argument in the @workflow.defn decorator to false.
The entire Workflow will run without sandbox restrictions.
@workflow.def(sandboxed=False)
Skip Sandboxing for a Worker
To skip a sandbox environment for a Worker, set the workflow_runner keyword argument of the Worker init to UnsandboxedWorkflowRunner().
Customize the sandbox
When creating the Worker, the workflow_runner defaults to SandboxedWorkflowRunner().
The SandboxedWorkflowRunner init accepts a restrictions keyword argument that defines a set of restrictions to apply to this sandbox.
The SandboxRestrictions dataclass is immutable and contains three fields that can be customized, but only two have notable values.
Passthrough modules
By default, the sandbox completely reloads non-standard-library and non-Temporal modules for every workflow run. Passing through a module means that the module will not be reloaded every time the Workflow runs. Instead, the module will be imported from outside the sandbox and used directly in the Workflow. This can improve performance because importing a module can be a time-consuming process, and passing through a module can avoid this overhead.
It is important to note that you should only import known-side-effect-free third-party modules: meaning they don't have any unintended consequences when imported and used multiple times. This is because passing through a module means that it will be used multiple times in a workflow without being reloaded, so any side effects it has will be repeated. For this reason, it's recommended to only pass through modules that are known to be deterministic, meaning they will always produce the same output given the same input.
One way to pass through a module is at import time in the workflow file using the imports_passed_through context manager.
# my_workflow_file.py
from temporalio import workflow
with workflow.unsafe.imports_passed_through():
import pydantic
@workflow.defn
class MyWorkflow:
# ...
Alternatively, this can be done at worker creation time by customizing the runner's restrictions.
my_worker = Worker(
...,
workflow_runner=SandboxedWorkflowRunner(
restrictions=SandboxRestrictions.default.with_passthrough_modules("pydantic")
)
)
In both of these cases, now the pydantic module will be passed through from outside the sandbox instead of being reloaded for every Workflow run.
Invalid module members
invalid_module_members includes modules that cannot be accessed.
Checks are compared against the fully qualified path to the item.
For example, to remove a restriction on datetime.date.today(), see the following example.
my_restrictions = dataclasses.replace(
SandboxRestrictions.default,
invalid_module_members=SandboxRestrictions.invalid_module_members_default.with_child_unrestricted(
"datetime", "date", "today",
),
)
my_worker = Worker(..., workflow_runner=SandboxeWorkflowRunner(restrictions=my_restrictions))
Restrictions can also be added by piping (|) together matchers.
The following example restricts the datetime.date class from being used.
my_restrictions = dataclasses.replace(
SandboxRestrictions.default,
invalid_module_members=SandboxRestrictions.invalid_module_members_default | SandboxMatcher(
children={"datetime": SandboxMatcher(use={"date"})},
),
)
my_worker = Worker(..., workflow_runner=SandboxeWorkflowRunner(restrictions=my_restrictions))
For more information on the Python sandbox, see the following resources.