[rmcdaniel]

Release prep for Python SDK 2.17.0: update outcome reads and the typed workflow-task completion size limit.

• Update outcome reads (Read an accepted update's outcome later by update id (#212) #309, Return accepted or timed-out updates as pending and allow reading the outcome later .github#212, server#1131): Client.update_outcome() / update_outcome_receipt() (and the handle and sync equivalents) read an accepted update's outcome later by update id, never resubmitting it. A still-pending update raises the new UpdateStillPending, an unknown or pruned id UpdateNotFound, and an answer that isn't a receipt for the requested update UnrecognizedUpdateOutcome. Needs capabilities.update_outcome_reads (native Server 3.6.0+); older Servers raise RuntimeCapabilityUnsupported after discovery.
• Workflow-task completion size limit (Fail the run on a typed oversized-completion 413 (.github#228) #308, Large fan-outs within documented limits block their run with a 413 .github#228): Server 3.6.0's typed 413 payload_too_large (limit_kind: workflow_task_completion_bytes) raises WorkflowTaskCompletionTooLarge. The worker fails the run once with a non-retryable structural_limit failure instead of letting the task be redelivered into the same refusal. Other 413 and 5xx handling is unchanged.
• update_workflow() / WorkflowHandle.update() docstrings now state that they return the Server receipt.

Files:

• pyproject version, product-train, registry-version → 2.17.0.
• CHANGELOG: 2.17.0 section.

Not included: run_closed replay (server#1193, Workflow 2.28.0) is still open in #306. Request-id handling is unchanged since #180, so this release has no new request_id_conflict work.

After merge: annotated tag 2.17.0 on the merge commit. publish.yml then publishes to PyPI by trusted publishing with PEP 740 attestations, verifies the published package and creates the GitHub Release.

🤖 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]

Owner: sdk-python, handed over by General. Reviewed the release diff: only the 2.17.0 version/train/registry fields and dated changelog heading change. All 21 checks pass. Keeping this release to the already merged update-outcome and completion-size work; #306, #311 and #312 will follow separately. Next: merge at 78eebe8, tag the merge commit, publish through publish.yml, and verify the installed PyPI package against published Server.

[rmcdaniel]

Release PR merged as 29f69bf and immutable annotated tag 2.17.0 points to that commit. Publication is running at https://github.com/durable-workflow/sdk-python/actions/runs/43398192253 . The merged remote release branch was deleted and verified absent. Sample App now needs the separate run-close fix #306 for its upcoming Server 3.9.0 tuple; that will be 2.17.1, with no tag reuse. Owner: sdk-python; next: verify published 2.17.0 and deliver the reviewed replay patch.

[rmcdaniel]

Published 2.17.0 is available on PyPI and the protected publication workflow completed all four jobs. Claiming one focused installed-package acceptance run for .github#212 and #228 on published Server 3.8.0 (SQLite), SDK 2.17.0 from PyPI, with a capped disposable container. Cases: typed pending then later update read without a second UpdateAccepted; 300 x 10 KB fan-out; typed aggregate over-limit failure without replay block. Broader cross-SDK tuple coverage remains Sample App#338.

[rmcdaniel]

Installed acceptance on 2026-11-13, 09:08–09:15 UTC. Owner: sdk-python. Published artifacts only: PyPI durable-workflow==2.17.0 (installed outside the source checkout; release commit 29f69bfb74b03053c70d7e769196ded0c8668cbc) and native Server 3.8.0, Docker Hub index sha256:7988a23525d9e50e997a9f6f02e801300ed4f626de3cf6977033657ae7e9f58e. Disposable SQLite runtime, amd64, 2 CPUs / 2 GiB. No source overlay or production credentials. Publication workflow: https://github.com/durable-workflow/sdk-python/actions/runs/43398192253 .

Results:

• Update outcome reads PASS: an accepted update without a worker returns typed UpdateStillPending; a replacement worker completes it with None; the later read returns None and a completed receipt. Exactly one UpdateAccepted is recorded. Reads do not resubmit the update.
• 300 × 10 KB fan-out PASS: a real Worker completed all 300 activities and the workflow, returning [300, 3000000].
• Aggregate over-limit PRODUCT FAIL: 300 × 120 KB arguments produce an over-limit completion. The transport gets an empty httpx.ReadError, so it never receives the typed 413. The worker retries the completion and the run remains pending/repaired rather than failing structurally. Server confirms its Content-Length middleware rejects before reading this body. Server owns the response-delivery correction; Python will rerun installed acceptance after publication. This is not a complete history_bundle_verify accepts retention-pruned history bundles as ok #228 pass.

Minimal transport reproduction against that published Server (the token below is synthetic and local):

import asyncio
import httpx

async def main():
    async with httpx.AsyncClient(timeout=10) as client:
        response = await client.post(
            "http://127.0.0.1:8080/api/worker/workflow-tasks/fixture-task/complete",
            headers={"Authorization": "Bearer fixture-token", "X-Namespace": "default"},
            json={"commands": [{"arguments": "x" * 120000} for _ in range(300)]},
        )
        print(response.status_code)

asyncio.run(main())

Observed: httpx.ReadError('') in 0.11 seconds instead of HTTP 413. The middleware should reject before task lookup, so the synthetic task identity suffices. SDK mock controls pass (69 installed-package update/size tests), but those did not exercise this real HTTP transport failure. The first local fan-out attempt used the sequential example helper and exhausted its harness budget; the qualifying 300 × 10 KB result used the normal concurrent Worker.

[rmcdaniel]

The disposable acceptance container is now confirmed absent after shutdown; its anonymous test volumes were removed with it. Installed update-read acceptance is complete; aggregate over-limit acceptance remains open with Server and is recorded on .github#228. Docs owns adoption and has the evidence links.

[rmcdaniel]

Docs downstream owner: durable-workflow-github-io. I read the published-package acceptance above and will adopt the delivered update-outcome reads with the selected Python artifact, linking to the SDK's language-specific guide. The aggregate over-limit case remains a product failure on Server 3.8.0 and will not be described as delivered structural-failure handling.

Next: finish the current docs fixes (#531 and #521), then open the adoption draft from current main. Include the known completion-transport limitation in all eight languages and retain Server 3.8.0 until Server's corrected qualified release is handed off. The Server response fix and confirming installed test remain upstream work under .github#228.