aws-durable-execution-sdk-python 2.0.1__tar.gz → 2.1.0__tar.gz

aws_durable_execution_sdk_python-2.1.0/PKG-INFO

@@ -0,0 +1,261 @@
+Metadata-Version: 2.5
+Name: aws-durable-execution-sdk-python
+Version: 2.1.0
+Summary: AWS Durable Execution SDK for Python
+Project-URL: Documentation, https://github.com/aws/aws-durable-execution-sdk-python#readme
+Project-URL: Issues, https://github.com/aws/aws-durable-execution-sdk-python/issues
+Project-URL: Source, https://github.com/aws/aws-durable-execution-sdk-python
+Author-email: AWS durable-execution-dev <durable-execution-dev@amazon.com>
+License-Expression: Apache-2.0
+Classifier: Development Status :: 4 - Beta
+Classifier: Programming Language :: Python
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Programming Language :: Python :: Implementation :: CPython
+Classifier: Programming Language :: Python :: Implementation :: PyPy
+Requires-Python: >=3.11
+Requires-Dist: boto3>=1.43.114
+Description-Content-Type: text/markdown
+
+# AWS Durable Execution SDK for Python
+
+[![Build](https://github.com/aws/aws-durable-execution-sdk-python/actions/workflows/ci.yml/badge.svg)](https://github.com/aws/aws-durable-execution-sdk-python/actions/workflows/ci.yml)
+[![PyPI - Version](https://img.shields.io/pypi/v/aws-durable-execution-sdk-python.svg)](https://pypi.org/project/aws-durable-execution-sdk-python)
+[![PyPI - Python Version](https://img.shields.io/pypi/pyversions/aws-durable-execution-sdk-python.svg)](https://pypi.org/project/aws-durable-execution-sdk-python)
+[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/aws/aws-durable-execution-sdk-python/badge)](https://scorecard.dev/viewer/?uri=github.com/aws/aws-durable-execution-sdk-python)
+[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://github.com/aws/aws-durable-execution-sdk-python/blob/main/LICENSE)
+
+-----
+
+Build reliable, long-running AWS Lambda workflows with checkpointed steps, waits, callbacks, and parallel execution.
+
+## ✨ Key Features
+
+- **Automatic checkpointing** - Resume execution after Lambda pauses or restarts
+- **Durable steps** - Run work with retry strategies and deterministic replay
+- **Waits and callbacks** - Pause for time or external signals without blocking Lambda
+- **Parallel and map operations** - Fan out work with configurable completion criteria
+- **Child contexts** - Structure complex workflows into isolated subflows
+- **Replay-safe logging** - Use `context.logger` for structured, de-duplicated logs
+- **Local and cloud testing** - Validate workflows with the testing SDK
+
+## 📦 Packages
+
+| Package | Description | Version |
+| --- | --- | --- |
+| `aws-durable-execution-sdk-python` | Execution SDK for Lambda durable functions | [![PyPI - Version](https://img.shields.io/pypi/v/aws-durable-execution-sdk-python.svg)](https://pypi.org/project/aws-durable-execution-sdk-python) |
+| `aws-durable-execution-sdk-python-testing` | Local/cloud test runner and pytest helpers | [![PyPI - Version](https://img.shields.io/pypi/v/aws-durable-execution-sdk-python-testing.svg)](https://pypi.org/project/aws-durable-execution-sdk-python-testing) |
+
+## Dynamic instrumentation plugins
+
+Instrumentation plugins can be selected at Lambda cold start without importing
+them in the function artifact. Install a provider package in the function or a
+Lambda layer, then set an ordered allow-list:
+
+```text
+DURABLE_EXECUTION_PLUGINS=otel-invocation,example_audit
+```
+
+The SDK resolves those names from the `aws_durable_execution.plugins` Python
+entry-point group when the decorated handler is initialized. An unset or blank
+variable preserves the existing behavior. The decorator's `plugins` argument
+remains supported; explicit plugins run first and take precedence when a
+dynamic provider creates the same concrete plugin type.
+
+Provider packages expose a versioned factory:
+
+```python
+from aws_durable_execution_sdk_python.plugin import (
+    DurableInstrumentationPlugin,
+    DurableInstrumentationPluginProvider,
+)
+
+
+class AuditPlugin(DurableInstrumentationPlugin):
+    pass
+
+
+AUDIT_PLUGIN_PROVIDER = DurableInstrumentationPluginProvider(
+    plugin_type=AuditPlugin,
+    factory=AuditPlugin,
+    plugin_api_version=1,
+)
+```
+
+Register the provider in the package's `pyproject.toml`:
+
+```toml
+[project.entry-points."aws_durable_execution.plugins"]
+example_audit = "example_audit:AUDIT_PLUGIN_PROVIDER"
+```
+
+Set `plugin_api_version` to the literal API version the provider implements.
+Update it only after verifying the provider against that API version.
+
+Provider names must be unique across installed distributions. Missing,
+ambiguous, incompatible, or invalid providers raise `PluginLoadError` during
+handler initialization with the provider and distribution details.
+
+### Selecting an OpenTelemetry view
+
+Enable at most one of `InvocationOtelPlugin` and `ExecutionOtelPlugin`. This
+constraint applies to the combined `plugins=[...]` argument and
+`DURABLE_EXECUTION_PLUGINS=otel-invocation` or `otel-execution` selection.
+Core 2.1+ with OTel 1.1+ rejects both at cold start with `PluginLoadError` naming the
+conflicting views; keep only one. Choose Invocation for work within each Lambda
+invocation or Execution for logical operations across the durable execution.
+Unrelated instrumentation plugins can run alongside either view. OTel 1.1 requires core 2.1 or later for the invocation-worker lifecycle as well
+as view-exclusivity validation. Release core 2.1 before releasing OTel 1.1.
+
+Plugin authors explicitly opt in by declaring
+`__durable_registration_api__ = 1` on a plugin class. That class and its subclasses
+have their optional `exclusive_group` metadata validated and their
+optional `on_registration_result(registered)` callback invoked. A missing group
+or `None` adds no exclusivity constraint. The callback can release rejected
+constructor resources and must preserve resources from earlier accepted use.
+
+The first class declaring the marker in the method resolution order gates
+registration and selects the callback contract. An explicit marker other than
+the integer `1` shadows an ancestor's opt-in and disables this capability.
+Once enabled, every class in the MRO explicitly declaring the integer `1`
+contributes its resolved `exclusive_group`. These constraints accumulate:
+repeating the marker with a new group adds to inherited groups rather than
+replacing them, and `None` does not erase an inherited constraint. A group is
+counted once per plugin registration even if several ancestors declare it.
+Unmarked classes' coincidental same-named legacy fields/helpers remain inert.
+Subclasses of the bundled OTel views therefore retain the view group when they
+add their own group. Repeat the marker to add a group or customize the callback;
+the callback is still notified once per plugin. Plugins with no marker anywhere
+in their hierarchy retain their existing attributes/helpers. The generic plugin base defines
+neither attribute nor hook, and provider API version 1 and existing plugin
+lifecycle order are unchanged.
+
+### Invocation worker lifecycle
+
+The existing `on_invocation_start` and `on_invocation_end` hooks run on the
+handler's invocation worker, both in registration order. Start hooks finish
+before background checkpoint processing begins. The same worker runs the handler
+(including its `finally` blocks), prepares the existing serialized output or
+error, checkpoints large results when necessary, joins registered branches while
+checkpointing is available, stops and waits for checkpoint processing, then calls
+End before returning the outcome. The caller shuts down the handler executor.
+There is no separate handler-context hook or context-manager plugin API.
+
+When plugins are registered, the worker begins with a copy of the caller's
+context-variable bindings. Successful Start bindings flow into later Start hooks,
+the handler, serialization and resource cleanup. A later successful Start may
+replace an earlier binding. If a Start hook raises, its new bindings are discarded
+for subsequent work; its End still runs in the original Context so its tokens can
+be reset. End hooks retain forward registration order, not reverse stack order,
+so they must not rely on observing a stack-like unwind of other plugins' contexts.
+Each SDK-managed `map` or `parallel` branch admission, including an in-process
+resume, receives a fresh copy of the coordinator's bindings when plugins are
+registered. Branch changes remain local even when pool threads are reused.
+User-created threads retain normal Python context-variable behavior; without
+registered plugins, SDK branch submission keeps its existing behavior.
+The worker's invocation context is discarded on return, including after plugin
+cleanup failures, leaving the host's bindings unchanged. This isolates bindings,
+not mutations to shared objects or external side effects. Without plugins, the
+handler retains its existing fresh-worker context behavior.
+
+These lifecycle guarantees require core 2.1.0 or later. The OTel 1.1 plugin
+requires that core version and uses the existing Start/End hooks. Upgrading the
+core alone with OTel 1.0 isolates worker bindings, but does not add the newer
+Invocation-view fallback to that older plugin; upgrade both packages for it.
+Provider API version 1 and the independent registration API are unchanged.
+
+### Chained-invoke propagation
+
+A new invoke START collects synchronous plugin metadata after resolving its
+operation and target identity, before checkpointing. The SDK writes a non-blank
+`x_amzn_trace_id` contribution to the flat
+`ChainedInvokeOptions.XAmznTraceId` member. Function, tenant, payload, operation
+name and identity remain unchanged. The member is omitted without a contribution.
+Each invoke in a batch has its own metadata; this is not a request-wide header.
+
+The SDK-owned frozen `PropagationInput` carries `execution_arn`, `operation_id`,
+optional `parent_operation_id`, and `target_function_name`. Frozen
+`PropagationMetadata` has optional `x_amzn_trace_id`. Neither type depends on
+OpenTelemetry or generated service models. The optional synchronous plugin
+`provide_propagation_metadata(info)` hook defaults to no contribution.
+
+The collector keeps the first non-blank opaque value in configured order without
+trimming it. Equal values do not conflict; different later values log both plugin
+identities and a conflict count. Ordinary hook/getter/result/diagnostic failures
+are isolated; cancellation and other `BaseException` control signals keep their
+existing behavior. Replaying a checkpointed START, pending operation or terminal
+result does not call the hook. If a START was never committed, a later attempt
+can collect again; the callback is not exactly-once.
+
+This requires boto3 1.43.114 or newer, whose botocore dependency includes the
+published optional `ChainedInvokeOptions.XAmznTraceId` string field. The real
+botocore tests exercise its parameter validation and wire serialization without
+field removal, validation bypass or a model-capability fallback. Deployed backend
+delivery and downstream topology still require separate validation.
+Python has no `DistributedMapOptions` wrapper
+or distributed-map START API: its existing map/parallel operations use CONTEXT.
+The design's corresponding distributed-map field awaits that future modeled path.
+
+Release coordination still requires the compatible core/OTel minor versions.
+Existing valid core/plugin combinations retain prior tracing behavior; older
+cores without this optional contract contribute no new propagation metadata.
+Backend rollout and deployed downstream trace-topology validation remain pending.
+
+## 🚀 Quick Start
+
+Install the execution SDK:
+
+```console
+pip install aws-durable-execution-sdk-python
+```
+
+Create a durable Lambda handler:
+
+```python
+from aws_durable_execution_sdk_python import (
+    DurableContext,
+    StepContext,
+    durable_execution,
+    durable_step,
+)
+from aws_durable_execution_sdk_python.config import Duration
+
+@durable_step
+def validate_order(step_ctx: StepContext, order_id: str) -> dict:
+    step_ctx.logger.info("Validating order", extra={"order_id": order_id})
+    return {"order_id": order_id, "valid": True}
+
+@durable_execution
+def handler(event: dict, context: DurableContext) -> dict:
+    order_id = event["order_id"]
+    context.logger.info("Starting workflow", extra={"order_id": order_id})
+
+    validation = context.step(validate_order(order_id), name="validate_order")
+    if not validation["valid"]:
+        return {"status": "rejected", "order_id": order_id}
+
+    # simulate approval (real world: use wait_for_callback)
+    context.wait(duration=Duration.from_seconds(5), name="await_confirmation")
+
+    return {"status": "approved", "order_id": order_id}
+```
+
+## 📚 Documentation
+
+The complete documentation for the AWS Durable Execution SDK for Python lives on the AWS Documentation site:
+
+- **[AWS Durable Execution Documentation](https://docs.aws.amazon.com/durable-execution/)** - Concepts, getting started, core operations, advanced topics, and API reference
+- **[AWS Lambda Durable Functions Guide](https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html)** - How durable functions work on Lambda
+
+## 💬 Feedback & Support
+
+- [Bug report](https://github.com/aws/aws-durable-execution-sdk-python/issues/new?template=bug_report.yml)
+- [Feature request](https://github.com/aws/aws-durable-execution-sdk-python/issues/new?template=feature_request.yml)
+- [Documentation feedback](https://github.com/aws/aws-durable-execution-sdk-python/issues/new?template=documentation.yml)
+- [Contributing guide](CONTRIBUTING.md)
+
+## 📄 License
+
+See the [LICENSE](https://github.com/aws/aws-durable-execution-sdk-python/blob/main/LICENSE) file for our project's licensing.

aws_durable_execution_sdk_python-2.1.0/README.md

@@ -0,0 +1,240 @@
+# AWS Durable Execution SDK for Python
+
+[![Build](https://github.com/aws/aws-durable-execution-sdk-python/actions/workflows/ci.yml/badge.svg)](https://github.com/aws/aws-durable-execution-sdk-python/actions/workflows/ci.yml)
+[![PyPI - Version](https://img.shields.io/pypi/v/aws-durable-execution-sdk-python.svg)](https://pypi.org/project/aws-durable-execution-sdk-python)
+[![PyPI - Python Version](https://img.shields.io/pypi/pyversions/aws-durable-execution-sdk-python.svg)](https://pypi.org/project/aws-durable-execution-sdk-python)
+[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/aws/aws-durable-execution-sdk-python/badge)](https://scorecard.dev/viewer/?uri=github.com/aws/aws-durable-execution-sdk-python)
+[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://github.com/aws/aws-durable-execution-sdk-python/blob/main/LICENSE)
+
+-----
+
+Build reliable, long-running AWS Lambda workflows with checkpointed steps, waits, callbacks, and parallel execution.
+
+## ✨ Key Features
+
+- **Automatic checkpointing** - Resume execution after Lambda pauses or restarts
+- **Durable steps** - Run work with retry strategies and deterministic replay
+- **Waits and callbacks** - Pause for time or external signals without blocking Lambda
+- **Parallel and map operations** - Fan out work with configurable completion criteria
+- **Child contexts** - Structure complex workflows into isolated subflows
+- **Replay-safe logging** - Use `context.logger` for structured, de-duplicated logs
+- **Local and cloud testing** - Validate workflows with the testing SDK
+
+## 📦 Packages
+
+| Package | Description | Version |
+| --- | --- | --- |
+| `aws-durable-execution-sdk-python` | Execution SDK for Lambda durable functions | [![PyPI - Version](https://img.shields.io/pypi/v/aws-durable-execution-sdk-python.svg)](https://pypi.org/project/aws-durable-execution-sdk-python) |
+| `aws-durable-execution-sdk-python-testing` | Local/cloud test runner and pytest helpers | [![PyPI - Version](https://img.shields.io/pypi/v/aws-durable-execution-sdk-python-testing.svg)](https://pypi.org/project/aws-durable-execution-sdk-python-testing) |
+
+## Dynamic instrumentation plugins
+
+Instrumentation plugins can be selected at Lambda cold start without importing
+them in the function artifact. Install a provider package in the function or a
+Lambda layer, then set an ordered allow-list:
+
+```text
+DURABLE_EXECUTION_PLUGINS=otel-invocation,example_audit
+```
+
+The SDK resolves those names from the `aws_durable_execution.plugins` Python
+entry-point group when the decorated handler is initialized. An unset or blank
+variable preserves the existing behavior. The decorator's `plugins` argument
+remains supported; explicit plugins run first and take precedence when a
+dynamic provider creates the same concrete plugin type.
+
+Provider packages expose a versioned factory:
+
+```python
+from aws_durable_execution_sdk_python.plugin import (
+    DurableInstrumentationPlugin,
+    DurableInstrumentationPluginProvider,
+)
+
+
+class AuditPlugin(DurableInstrumentationPlugin):
+    pass
+
+
+AUDIT_PLUGIN_PROVIDER = DurableInstrumentationPluginProvider(
+    plugin_type=AuditPlugin,
+    factory=AuditPlugin,
+    plugin_api_version=1,
+)
+```
+
+Register the provider in the package's `pyproject.toml`:
+
+```toml
+[project.entry-points."aws_durable_execution.plugins"]
+example_audit = "example_audit:AUDIT_PLUGIN_PROVIDER"
+```
+
+Set `plugin_api_version` to the literal API version the provider implements.
+Update it only after verifying the provider against that API version.
+
+Provider names must be unique across installed distributions. Missing,
+ambiguous, incompatible, or invalid providers raise `PluginLoadError` during
+handler initialization with the provider and distribution details.
+
+### Selecting an OpenTelemetry view
+
+Enable at most one of `InvocationOtelPlugin` and `ExecutionOtelPlugin`. This
+constraint applies to the combined `plugins=[...]` argument and
+`DURABLE_EXECUTION_PLUGINS=otel-invocation` or `otel-execution` selection.
+Core 2.1+ with OTel 1.1+ rejects both at cold start with `PluginLoadError` naming the
+conflicting views; keep only one. Choose Invocation for work within each Lambda
+invocation or Execution for logical operations across the durable execution.
+Unrelated instrumentation plugins can run alongside either view. OTel 1.1 requires core 2.1 or later for the invocation-worker lifecycle as well
+as view-exclusivity validation. Release core 2.1 before releasing OTel 1.1.
+
+Plugin authors explicitly opt in by declaring
+`__durable_registration_api__ = 1` on a plugin class. That class and its subclasses
+have their optional `exclusive_group` metadata validated and their
+optional `on_registration_result(registered)` callback invoked. A missing group
+or `None` adds no exclusivity constraint. The callback can release rejected
+constructor resources and must preserve resources from earlier accepted use.
+
+The first class declaring the marker in the method resolution order gates
+registration and selects the callback contract. An explicit marker other than
+the integer `1` shadows an ancestor's opt-in and disables this capability.
+Once enabled, every class in the MRO explicitly declaring the integer `1`
+contributes its resolved `exclusive_group`. These constraints accumulate:
+repeating the marker with a new group adds to inherited groups rather than
+replacing them, and `None` does not erase an inherited constraint. A group is
+counted once per plugin registration even if several ancestors declare it.
+Unmarked classes' coincidental same-named legacy fields/helpers remain inert.
+Subclasses of the bundled OTel views therefore retain the view group when they
+add their own group. Repeat the marker to add a group or customize the callback;
+the callback is still notified once per plugin. Plugins with no marker anywhere
+in their hierarchy retain their existing attributes/helpers. The generic plugin base defines
+neither attribute nor hook, and provider API version 1 and existing plugin
+lifecycle order are unchanged.
+
+### Invocation worker lifecycle
+
+The existing `on_invocation_start` and `on_invocation_end` hooks run on the
+handler's invocation worker, both in registration order. Start hooks finish
+before background checkpoint processing begins. The same worker runs the handler
+(including its `finally` blocks), prepares the existing serialized output or
+error, checkpoints large results when necessary, joins registered branches while
+checkpointing is available, stops and waits for checkpoint processing, then calls
+End before returning the outcome. The caller shuts down the handler executor.
+There is no separate handler-context hook or context-manager plugin API.
+
+When plugins are registered, the worker begins with a copy of the caller's
+context-variable bindings. Successful Start bindings flow into later Start hooks,
+the handler, serialization and resource cleanup. A later successful Start may
+replace an earlier binding. If a Start hook raises, its new bindings are discarded
+for subsequent work; its End still runs in the original Context so its tokens can
+be reset. End hooks retain forward registration order, not reverse stack order,
+so they must not rely on observing a stack-like unwind of other plugins' contexts.
+Each SDK-managed `map` or `parallel` branch admission, including an in-process
+resume, receives a fresh copy of the coordinator's bindings when plugins are
+registered. Branch changes remain local even when pool threads are reused.
+User-created threads retain normal Python context-variable behavior; without
+registered plugins, SDK branch submission keeps its existing behavior.
+The worker's invocation context is discarded on return, including after plugin
+cleanup failures, leaving the host's bindings unchanged. This isolates bindings,
+not mutations to shared objects or external side effects. Without plugins, the
+handler retains its existing fresh-worker context behavior.
+
+These lifecycle guarantees require core 2.1.0 or later. The OTel 1.1 plugin
+requires that core version and uses the existing Start/End hooks. Upgrading the
+core alone with OTel 1.0 isolates worker bindings, but does not add the newer
+Invocation-view fallback to that older plugin; upgrade both packages for it.
+Provider API version 1 and the independent registration API are unchanged.
+
+### Chained-invoke propagation
+
+A new invoke START collects synchronous plugin metadata after resolving its
+operation and target identity, before checkpointing. The SDK writes a non-blank
+`x_amzn_trace_id` contribution to the flat
+`ChainedInvokeOptions.XAmznTraceId` member. Function, tenant, payload, operation
+name and identity remain unchanged. The member is omitted without a contribution.
+Each invoke in a batch has its own metadata; this is not a request-wide header.
+
+The SDK-owned frozen `PropagationInput` carries `execution_arn`, `operation_id`,
+optional `parent_operation_id`, and `target_function_name`. Frozen
+`PropagationMetadata` has optional `x_amzn_trace_id`. Neither type depends on
+OpenTelemetry or generated service models. The optional synchronous plugin
+`provide_propagation_metadata(info)` hook defaults to no contribution.
+
+The collector keeps the first non-blank opaque value in configured order without
+trimming it. Equal values do not conflict; different later values log both plugin
+identities and a conflict count. Ordinary hook/getter/result/diagnostic failures
+are isolated; cancellation and other `BaseException` control signals keep their
+existing behavior. Replaying a checkpointed START, pending operation or terminal
+result does not call the hook. If a START was never committed, a later attempt
+can collect again; the callback is not exactly-once.
+
+This requires boto3 1.43.114 or newer, whose botocore dependency includes the
+published optional `ChainedInvokeOptions.XAmznTraceId` string field. The real
+botocore tests exercise its parameter validation and wire serialization without
+field removal, validation bypass or a model-capability fallback. Deployed backend
+delivery and downstream topology still require separate validation.
+Python has no `DistributedMapOptions` wrapper
+or distributed-map START API: its existing map/parallel operations use CONTEXT.
+The design's corresponding distributed-map field awaits that future modeled path.
+
+Release coordination still requires the compatible core/OTel minor versions.
+Existing valid core/plugin combinations retain prior tracing behavior; older
+cores without this optional contract contribute no new propagation metadata.
+Backend rollout and deployed downstream trace-topology validation remain pending.
+
+## 🚀 Quick Start
+
+Install the execution SDK:
+
+```console
+pip install aws-durable-execution-sdk-python
+```
+
+Create a durable Lambda handler:
+
+```python
+from aws_durable_execution_sdk_python import (
+    DurableContext,
+    StepContext,
+    durable_execution,
+    durable_step,
+)
+from aws_durable_execution_sdk_python.config import Duration
+
+@durable_step
+def validate_order(step_ctx: StepContext, order_id: str) -> dict:
+    step_ctx.logger.info("Validating order", extra={"order_id": order_id})
+    return {"order_id": order_id, "valid": True}
+
+@durable_execution
+def handler(event: dict, context: DurableContext) -> dict:
+    order_id = event["order_id"]
+    context.logger.info("Starting workflow", extra={"order_id": order_id})
+
+    validation = context.step(validate_order(order_id), name="validate_order")
+    if not validation["valid"]:
+        return {"status": "rejected", "order_id": order_id}
+
+    # simulate approval (real world: use wait_for_callback)
+    context.wait(duration=Duration.from_seconds(5), name="await_confirmation")
+
+    return {"status": "approved", "order_id": order_id}
+```
+
+## 📚 Documentation
+
+The complete documentation for the AWS Durable Execution SDK for Python lives on the AWS Documentation site:
+
+- **[AWS Durable Execution Documentation](https://docs.aws.amazon.com/durable-execution/)** - Concepts, getting started, core operations, advanced topics, and API reference
+- **[AWS Lambda Durable Functions Guide](https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html)** - How durable functions work on Lambda
+
+## 💬 Feedback & Support
+
+- [Bug report](https://github.com/aws/aws-durable-execution-sdk-python/issues/new?template=bug_report.yml)
+- [Feature request](https://github.com/aws/aws-durable-execution-sdk-python/issues/new?template=feature_request.yml)
+- [Documentation feedback](https://github.com/aws/aws-durable-execution-sdk-python/issues/new?template=documentation.yml)
+- [Contributing guide](CONTRIBUTING.md)
+
+## 📄 License
+
+See the [LICENSE](https://github.com/aws/aws-durable-execution-sdk-python/blob/main/LICENSE) file for our project's licensing.

{aws_durable_execution_sdk_python-2.0.1 → aws_durable_execution_sdk_python-2.1.0}/pyproject.toml

@@ -21,7 +21,7 @@ classifiers = [
   "Programming Language :: Python :: Implementation :: CPython",
   "Programming Language :: Python :: Implementation :: PyPy",
 ]
-dependencies = ["boto3>=1.42.1"]
+dependencies = ["boto3>=1.43.114"]
 
 [project.urls]
 Documentation = "https://github.com/aws/aws-durable-execution-sdk-python#readme"

{aws_durable_execution_sdk_python-2.0.1 → aws_durable_execution_sdk_python-2.1.0}/src/aws_durable_execution_sdk_python/__about__.py

@@ -1,4 +1,4 @@
 # SPDX-FileCopyrightText: 2025-present Amazon.com, Inc. or its affiliates.
 #
 # SPDX-License-Identifier: Apache-2.0
-__version__ = "2.0.1"
+__version__ = "2.1.0"

{aws_durable_execution_sdk_python-2.0.1 → aws_durable_execution_sdk_python-2.1.0}/src/aws_durable_execution_sdk_python/concurrency/executor.py

@@ -2,6 +2,7 @@
 
 from __future__ import annotations
 
+import contextvars
 import heapq
 import logging
 import queue
@@ -44,7 +45,7 @@ from aws_durable_execution_sdk_python.identifier import (
     OperationIdentifier,
     OperationIdNamespace,
 )
-from aws_durable_execution_sdk_python.lambda_service import ErrorObject
+from aws_durable_execution_sdk_python.lambda_service import ErrorObject, OperationType
 from aws_durable_execution_sdk_python.operation.child import child_handler
 
 
@@ -183,6 +184,7 @@ class ConcurrentExecutor(Generic[CallableType, ResultType]):
                 executable.index
             ),
             sub_type=self.sub_type_iteration,
+            operation_type=OperationType.CONTEXT,
             parent_id=executor_context._parent_id,  # noqa: SLF001
             name=self.get_iteration_name(executable.index),
         )
@@ -291,13 +293,25 @@ class ConcurrentExecutor(Generic[CallableType, ResultType]):
 
         def submit(branch: Branch[CallableType, ResultType]) -> None:
             branch.start()
-            pool.submit(
-                self._branch_worker,
-                execution_state,
-                executor_context,
-                events,
-                branch.executable,
-            )
+            if execution_state._plugin_executor._plugins:  # noqa: SLF001
+                # Every admission/resume gets its own Context. Branch bindings
+                # cannot leak into siblings, the coordinator, or reused workers.
+                pool.submit(
+                    contextvars.copy_context().run,
+                    self._branch_worker,
+                    execution_state,
+                    executor_context,
+                    events,
+                    branch.executable,
+                )
+            else:
+                pool.submit(
+                    self._branch_worker,
+                    execution_state,
+                    executor_context,
+                    events,
+                    branch.executable,
+                )
 
         try:
             # Only rebuild the items snapshot after a terminal event changes