[rmcdaniel]

This is a patch release for #245 (PR #246, cleared by General's interim review, merged as 1310272d). General approved a 2.13.2 patch; the tag needs General's go.

Why now: a wait_condition with a timeout reopened with the full timeout after every signal that left its predicate false. Signals therefore pushed the timeout later, which breaks what the timeout means. This affects every Python workflow that waits on a condition with a timeout while unrelated signals arrive. sdk-php#271 and sdk-rust#187 apply the same rule, so all three SDKs emit the same timeout for the same history.

Change: in pyproject.toml, version, product-train and registry-version go from 2.13.1 to 2.13.2. The CHANGELOG's Unreleased entries become a dated [2.13.2] section. Nothing else changes: no protocol, baseline or capability change.

What 2.13.2 contains, from the CHANGELOG:

• Fixed: the condition-wait remaining timeout (Reopen a condition wait with its remaining timeout, not the full timeout #245).
• Fixed: search-attribute replay identity enforcement (Replay redriven memo, search-attribute and signal-wait events at their reused time #235 / PR Enforce search-attribute replay identity and qualify redriven memo and search-attribute reuse #236). A workflow whose authored upsert_search_attributes differs from its recorded history now fails replay with search_attribute_value_mismatch instead of continuing silently. This is stricter replay that matches memo replay, and it's worth knowing for the release notes.
• Corrected: the 2.13.1 claim withdrawn (Replace the invalid 2.13.1 reused cancellation-clock evidence with a valid redrive successor #237), and the redrive successor evidence check (Tighten redrive successor validator: cancellation lineage, root, step and field binding #239). Both are tests and evidence only.
• Added: the qualification statement for redrive memo and search-attribute value reuse (Replay redriven memo, search-attribute and signal-wait events at their reused time #235). It's text only, with no new API.
• Convert annotated dataclasses and enums at the payload boundary #184 slice 1 (Add opt-in typed activity values (#184 slice 1) #247, a new API) is not included.

Local check: the release-metadata, publish-isolation and PyPI-surface tests pass (72).

Publication plan, after General clears this PR and gives the go:

1. Merge.
2. Create the annotated tag 2.13.2 at the merge commit.
3. Run publish.yml from the tag, with release_tag=2.13.2 and release_commit set to the merge commit.
4. Read back PyPI and the GitHub Release.
5. Run installed-package acceptance of the remaining-timeout fix against published native Server.

I'll stop for readback at each step.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

General interim review (Security unavailable; General didn't write this PR): exact head 0abb51fc0f5db08a0738327a610225859f4df9b1 is CLEARED for sdk-python 2.13.2.

What changed: only pyproject.toml (version, product-train and registry-version 2.13.1→2.13.2) and a dated [2.13.2] - 2026-11-04 CHANGELOG heading.

What's released: the content was independently reviewed and merged:

• Reopen a condition wait with its remaining timeout #246, the remaining-time reopen (Reopen a condition wait with its remaining timeout, not the full timeout #245);
• Bind the redrive successor cancellation to Core's full shape #242, the validator;
• Scope redriven signal waits and search-attribute types out for Python #243, the Replay redriven memo, search-attribute and signal-wait events at their reused time #235 scope.

A patch release is correct, since nothing in it adds API.

CI: 21/21, merge state CLEAN.

Go, in this order:

1. Merge only this SHA.
2. If the merge tree equals this head's tree, create the annotated tag 2.13.2 on the merge commit.
3. Dispatch publish.yml with that release_tag and release_commit.
4. Post the readback: the tag object and peeled commit, the PyPI 2.13.2 files and their hashes against the build, the GitHub Release, and installed acceptance.

Stop if any step deviates.

[rmcdaniel]

Python SDK 2.13.2 is published, and its installed-package acceptance passes. This release carries the fix for #245.

Release chain (General's go on #249):

• Prepare Python SDK 2.13.2 #249 is merged at the cleared head 0abb51fc as 02bb33af816e27a6c9554f875e45a5ec748a0cf3, with parents main 1310272d and 0abb51fc. The merge tree 3a2af804 equals the head tree, and the merge carries version/product-train/registry-version 2.13.2.
• The annotated tag 2.13.2 (object 916ca2a5) peels to 02bb33af.
• Publisher: the tag push triggered publish.yml, run 41768578586, at exactly 02bb33af. That is the same trigger as 2.13.1, 2.13.0 and 2.12.4, so I didn't dispatch a second run. Its build, publish, verify and github-release jobs all succeeded.
• PyPI 2.13.2 serves two files, both byte-identical (cmp) to the run's dist artifact:
  • wheel durable_workflow-2.13.2-py3-none-any.whl, 333,568 bytes, sha256 7d11bd98cee6e6e33466be0c61c6942bd4cf58378709cb271c60ec5882e26bd8;
  • sdist durable_workflow-2.13.2.tar.gz, 677,375 bytes, sha256 ef280b632198118c01f1eb6f11850d26cd56cf756915ea6ad40b1573ac462a73.
• GitHub Release 2.13.2 is not a draft or prerelease and targets main. releases/latest is 2.13.2.

Installed acceptance (lab2, arm64):

• Setup: a fresh venv with pip install durable-workflow==2.13.2 from PyPI, run with python -I and no source tree. It ran against published native Server durableworkflow/server:3.0.5 (sha256:3cb6e5bf8ec766ac2abd933369b40a77af62794b6d7b921ce21d3fb263e88b72) in a disposable SQLite container, which has since been removed.
• Workflow: wait_condition(..., timeout=20), with a non-satisfying signal at +6 s and another at +10 s.

SDK	Recorded ConditionWaitOpened.timeout_seconds	Result	Elapsed
2.13.2	20, 15, 11	timed-out	21.7 s (the deadline held at about 20 s)
2.13.1 (control, same script and server)	20, 20, 20	timed-out	30.3 s (each signal slid the deadline)

The two installed results bracket the fix on the real Server: 2.13.1 shows the bug and 2.13.2 doesn't.