This repository contains the AWS Durable Execution SDK for Python and its companion packages, used to author AWS Lambda durable functions.
Do not rely on this file for method signatures, configuration objects, or code examples. The canonical reference is the AWS Durable Execution SDK Developer Guide, which is maintained alongside SDK releases and covers TypeScript, Python, and Java. Key sections:
For Lambda service topics such as deployment, infrastructure as code, invocation, IAM permissions, and quotas, see the Lambda durable functions guide.
Durable functions use checkpoint and replay. After a wait, failure, or resume, code re-runs from the beginning. Completed steps return their checkpointed results without re-executing, and code outside steps runs again on every replay. This implies four rules:
- Code outside steps must be deterministic. Wrap timestamps, random values, UUID generation, API calls, and any other non-deterministic work in a step.
- Never call durable operations inside a step. Use a child context to group operations.
- Closure mutations inside steps are lost on replay. Return values from steps instead of mutating enclosing scope.
- Side effects outside steps repeat on every replay. Put side effects
in steps.
context.loggeris the exception: it is replay-aware and safe anywhere.
See Determinism and Replay for worked examples.
- Do not use
yaml.load()oryaml.load_all(), including withLoader=arguments or suppression comments. CodeQL and security scanners flag the unsafe call form even when the loader subclassesyaml.SafeLoader. - Use
yaml.safe_load()oryaml.safe_load_all()for plain YAML. - For CloudFormation or SAM templates with short-form tags such as
!Ref,!Sub,!GetAtt, or!If, use ayaml.SafeLoadersubclass with explicit tag constructors so the tags are preserved. - For custom safe loaders, instantiate the loader directly, call
get_single_data()or the equivalent multi-document API, and calldispose()in afinallyblock. This matches whatyaml.safe_load()does internally while preserving custom tag support. - Before finishing YAML-related changes, check Python code for unsafe call
forms:
rg -n --glob '*.py' "yaml\\.load\\b|yaml\\.load_all\\b|from yaml import load\\b|from yaml import load_all\\b" .
All changes MUST include related tests. At minimum, include unit tests. Include e2e integration tests (in the tests/e2e/ directory) when the change affects cross-component behavior, public API surfaces, or end-to-end workflows. For isolated bug fixes where a unit test alone sufficiently covers the fix, integration tests are not required.
Do NOT add or modify conformance tests without coordinating with the team. Conformance test requirements and the runner live in a separate repository (aws-durable-execution-conformance-tests). If a change warrants a new conformance test, note it in the PR description or open an issue in that repository.
- Packages live under
packages/: the core SDK (aws-durable-execution-sdk-python), the testing library (aws-durable-execution-sdk-python-testing), the OpenTelemetry plugin (aws-durable-execution-sdk-python-otel), and examples (aws-durable-execution-sdk-python-examples). - Read CONTRIBUTING.md before making changes. Use
hatchfor all tests, type checks, and formatting (for examplehatch run dev-core:test,hatch run dev-core:typecheck, andhatch fmt --checkfrom a package directory). - When the developer guide and the installed SDK source disagree, trust the source in this repository and report the discrepancy.