[zhongkechen]

Prepare the coordinated SDK 2.1.0, OTel 1.1.0 and testing 1.3.0 release from changes already merged to main as of October 21, 2026.

The branch contains main through c6383691eacca01ccbf0d76f0959a0de948e2ac3. This PR bumps the testing package from 1.2.1 to 1.3.0 and raises its minimum SDK version to 2.1.0 in both the published dependency metadata and the package-local Hatch test environment.

Package	Version on main	Release version
SDK	2.1.0	2.1.0
OTel	1.1.0	1.1.0
Testing	1.2.1	1.3.0

Currently unmerged PRs are excluded from this release and are not release prerequisites. In particular, #758, #795, #796 and aws/aws-durable-execution-conformance-tests#131 are deferred. Their callback delivery, replay telemetry, testing-state corrections and expanded conformance coverage are not included in the notes or validation below. The factory migration in #737 and the Telemetry Exporter promotion in #788 are also outside this release.

Intended combined release tag: sdk-v2.1.0,otel-v1.1.0,testing-v1.3.0.

Draft release notes

SDK 2.1.0

• Add optional plugin trace metadata to new chained-invoke START checkpoints and serialize XAmznTraceId; require boto3 >=1.43.114 (feat(plugin): propagate chained invoke trace context in START checkpoints #755).
• Return PENDING when the checkpoint token is revoked, including revocation observed during checkpoint cleanup (fix(sdk): answer PENDING on revoked token #757).
• Run invocation lifecycle callbacks and handler work on the handler worker, and isolate registered-plugin branch contexts (fix: run invocation lifecycle on handler worker #756).
• Reject competing OTel views before discovered plugin factories run (fix(otel): reject competing telemetry views #753).
• Use explicit operation types instead of inferring them from subtypes (fix(core): require explicit operation types #768).
• Reject replay checkpoints at virtual child operation IDs with NonDeterministicExecutionError (fix(core): reject checkpoints at virtual child ids #778).
• Skip plugin hook processing and full operation-map copies when no plugin is registered (fix(core): skip plugin hook work without plugins #781).

OTel 1.1.0

• Provide Root/Parent/Sampled metadata for new chained invokes, including unsampled operations (feat(plugin): propagate chained invoke trace context in START checkpoints #755).
• Correct operation and retry status mappings (fix(otel): correct exported status mappings #752).
• Enforce one telemetry view and restore log enrichment when reusing a previously rejected instance (fix(otel): reject competing telemetry views #753).
• Export sampled fallback roots early with stable anchor metadata (fix(otel): export sampled fallback roots early #754).
• Propagate and clean up handler-worker contexts (fix: run invocation lifecycle on handler worker #756).
• Require SDK >=2.1.0. The SDK must be available before installing this OTel version. The combined-release Lambda layer pins SDK 2.1.0 and includes its required runtime dependencies (feat(plugin): propagate chained invoke trace context in START checkpoints #755).

Testing 1.3.0

• Add experimental local pause_execution() / resume_execution() and paused-checkpoint simulation. Cloud-runner pause/resume remains unsupported (fix(sdk): answer PENDING on revoked token #757).
• Require SDK >=2.1.0 because pause/resume relies on the SDK returning PENDING when a checkpoint token is revoked (fix(sdk): answer PENDING on revoked token #757). Publish SDK 2.1.0 before testing 1.3.0 so the dependency can be resolved.
• Fail invalid non-PENDING handler outputs immediately and bound retries for PENDING responses with no pending operations (fix(testing): fail fast on invalid handler output #777, with regression coverage corrected in test: fix executor state in invalid-output tests #790).
• Include the virtual-clock, per-execution worker and local chained-invoke improvements already on main.

Compatibility and publication

This minor release retains the enum-based OperationSubType contract. The public subtype migration in #749 and the compatibility preparation in closed, unmerged #774 remain deferred to the next major release, as recorded in the closing decision. The minor-release classification of merged #768 is recorded in the compatibility discussion.

The current .github/workflows/pypi-publish.yml includes aws-durable-execution-sdk-python-telemetry-exporter unconditionally in both build and publish matrices. The exporter is outside this coordinated release scope, so that publishing-scope issue still needs to be resolved before publication. First publication of that distribution name requires its own release decision and PyPI trusted-publishing configuration under RELEASING.md; this is not a prerequisite to merge any currently open feature or fix PR.

Validation and remaining release checks

• Confirmed that the branch includes main through c6383691 and differs only in the testing version and its two SDK dependency declarations.
• Verified all three package versions, Python >=3.11 requirements, dependency declarations and the SDK 2.1.0 layer pin against the current head.
• Before the dependency-floor correction, workflows passed on 5b3a9a3b: Python package, Python 3.11–3.14, Cloud tests, Python 3.11–3.14, JS Examples, CodeQL and AI PR Review. AI workflow success does not replace a required approval.
• With SDK 2.1.0 and testing 1.3.0 on Python 3.14, hatch run dev-testing:test -q passed all 1,702 unit and end-to-end tests, including all pause/resume cases.
• Testing-package hatch fmt --check, hatch run dev-testing:typecheck (135 files), and the new commit's Conventional Commits check passed.
• Built the testing wheel and source distribution with hatch build; both declare aws-durable-execution-sdk-python>=2.1.0. Verified the requirement rejects SDK 2.0.1 and accepts 2.1.0 and later.
• hatch run dev-testing:js-examples --js-dir <prebuilt checkout> --no-build passed all 122 runnable JS example files with no retries or failures (4 selected files contain no cloud tests), using JS SDK commit 351786a5baec2062fce88ee0803fb2f2b07da3cf.
• Confirm that GitHub checks pass on the dependency-floor correction.
• Obtain the required repository approval and merge these release metadata changes. The PR author will perform the release merge.
• Resolve the Telemetry Exporter publishing-scope issue described above before publishing the combined release.
• On the final release main commit, confirm green CI, build the release artifacts, verify legal files and dependencies, and finalize the per-package notes and tag checks under RELEASING.md.

The dependency-floor correction addresses review 5605560893. This PR prepares the release metadata; publication remains subject to the release checks above.

[yaythomas]

before next release, please let's double-check how operation type works the type out from the subtype in plugin, since this is a plugin change it could probably do with going out in the same release. still investigating.

[zhongkechen]

@yaythomas I checked this and opened #768. Checkpoint-backed plugin hooks already use the explicit operation type, but local hooks could fall back to inferring it from subtype. #768 removes that fallback and OperationType.from_sub_type: OperationIdentifier now requires operation_type=, and every operation creator supplies it.

The new tests cover built-in operations across suspension/replay and checkpointed/virtual children whose subtype differs from their type. Core (1,821), OTel (668), and Insight (157) tests pass locally, with 98.33% core coverage; type checking and lint also pass. CI is still running.

Requiring operation_type= and removing OperationType.from_sub_type are source-breaking for callers that use those lower-level helpers directly. If these changes are considered non-breaking under the SDK's supported API contract, I recommend including #768 in the minor release; otherwise, it should go in a major release. #762 separately addresses loading unknown subtype values.

[yaythomas]

agree minor release is fine here.

this #749 change to make OperationSubType a str could impact Otel also, so we might want to consider making this 1st to avoid release churn?

Before we release, OTel and testing should accept a subtype that is a plain string.

If we make this change now, #749 won't need another OTel or testing release.

Change:

• OTel, in execution_plugin.py and invocation_plugin.py: replace info.sub_type.value with getattr(info.sub_type, "value", info.sub_type).
• Testing, in model.py: make the same replacement in the sub_type property. In the two places that parse with OperationSubType(...), keep the raw string when the value isn't a member.

Effect today: none. For every subtype the SDK records today, the new code returns the same value.

[zhongkechen]

@yaythomas #774 is now limited to metadata-read preparation in commit 1c2158d: the two OTel attribute builders and testing's history-event projection accept enum values or plain-string labels. Core and testing public subtype declarations remain unchanged.

The earlier claim in this reply that unknown labels are accepted by the checkpoint/typed-history parsers is withdrawn. Real endpoint validation found that passing an unknown string into the current core model can consume an in-memory checkpoint token before serialization fails; returning that string as an enum-typed history result also violates the declared contract. Both parser fallbacks have therefore been removed and are deferred until the core parsing, serialization, replay and public type work in issue #749 can be coordinated. Existing enum parsing and known-label identity are preserved.

The testing suite passes 1,615 tests; the final 210 focused exporter/history/endpoint tests and six-file type check pass, including state/token/retry controls on memory, filesystem and SQLite stores and an existing typed .value caller. The new head's CI is pending. #774 remains a separate preparation dependency for this release; it does not implement the full custom-subtype feature.

[yaythomas]

Should prob pin the min version of the sdk?

packages/aws-durable-execution-sdk-python-testing/pyproject.toml "aws-durable-execution-sdk-python>=1.0.0" → "aws-durable-execution-sdk-python>=2.1.0

Pause/resume needs SDK 2.1.0, but the package still requires only aws-durable-execution-sdk-python>=1.0.0. I ran main's full testing suite against SDK 2.0.1. 1,699 tests passed and 3 failed. All 3 failures are in tests/e2e/pause_resume_test.py. The SDK side of #757, which returns PENDING on a revoked token, exists only in 2.1.0.

(Turns out the >=1.0.0 floor was already wrong in 1.2.1 too 💀 Both 1.2.1 and main fail to import with SDK 1.1.0. On 1.0.0, main fails with an ImportError for TimestampConverter. Both import cleanly from SDK 1.1.2 on.)

New features

1. Virtual clock (#523). skip_time=True is now the default. Waits and step-retry delays finish instantly, and the history still records the original durations. The DURABLE_EXECUTION_TIME_SCALE env var is removed. I ran a handler that does context.wait(Duration.from_hours(1)) with main's defaults. It succeeded in 0.21 s.
2. Chained invoke in the local runner (#731). context.invoke now works locally. You register targets with register_durable_function() or register_function(). The web runner takes --function-configs.
3. Experimental pause/resume (#757). The local runner adds pause_execution() and resume_execution(). The cloud runner reports them as not implemented.
4. Local runner rework to behave like the service (#515, #516, #504).
5. Only one handler invocation runs at a time per execution.
6. Each execution gets its own worker that runs its tasks one at a time.
7. Map/parallel branches no longer all run on the scheduler thread.
8. Updated operation IDs carry over across resumed invocations.

Behavior changes

1. Lower default execution timeout. It drops from 900 s to 300 s, set by the new constructor argument execution_timeout=300.
2. run(timeout=...) is deprecated. Use run(execution_timeout=...) instead. The old keyword still works but raises a DeprecationWarning. Positional calls such as run(input, 60) keep their meaning, because the new second parameter does what the old timeout did.
3. Failed invocations without an error payload now fail the execution (#682). In 1.2.1 those executions succeeded.
4. Invalid handler output fails the execution right away (#777). The error is InvalidParameterValueException. Only a PENDING result with no pending operations is retried, up to 3 attempts. 1.2.1 retried every invalid output up to 5 times, 5 s apart.

Fixes

1. Local waits no longer hang when the scheduler loop is blocked (#498).
2. A due wait in a map/parallel branch now completes inside the running invocation. Before, the branch needed an extra invocation to resume (#588).
3. The cloud runner retries the temporary ResourceNotFoundException that GetDurableExecution can return right after invoke (#512).
4. The cloud runner fetches every page of execution history (#514).
5. The web server honors ReverseOrder on history requests (#595).
6. Blank execution ARNs are now rejected. Before, they registered a worker thread that never shut down (#636).
7. get_assertable_operations() excludes EXECUTION operations by type. Before, it dropped the first item in the list (#637).

[github-actions]

Codex AI review

No actionable findings in the version bump or SDK dependency-floor changes. Static review only; tests, package builds, and installed-package compatibility were not exercised.

Reviewed commit 8af550654dc2e16d7eb0fb621440cc9761a02124. Workflow run