Preserve accepted update failure diagnostics in Python clients

[rmcdaniel]

Published failure

Python SDK 2.4.2 maps an accepted update's handler failure (HTTP 422, update_status=failed) to InvalidArgument with an empty message. The Server response supplies failure_message, failure_id, update_id and run identity, but the SDK discards that response. Callers cannot distinguish a failed handler from malformed arguments or inspect the durable failure.

Confirmed in Sample App's live published update run, using PHP 2.2.3, Python 2.4.2, Rust 3.3.0 and Server 2.5.9 at sha256:11c11e11498b63e644d906e43f49810a1bc0b5298f750734fe0edb279c622bca. The durable UpdateCompleted event records codec error: update-probe-failure, a failure identity and the original accepted update. The Python exception is InvalidArgument('').

Acceptance

• Return a public typed UpdateFailed exception for a durably accepted handler failure, with a useful message, HTTP status, original response and workflow/run/update/failure identities.
• Preserve existing catch compatibility and distinguish argument errors, validator rejection and validation infrastructure failures.
• Cover both async and sync clients, message fallback and duplicate failed-update requests.
• Publish a qualified patch and update Sample App's tuple. Its real published client must assert the diagnostic against the durable failure and original identities, with one failed completion and a live original workflow.

Part of durable-workflow/.github#122. Source CI and the complete live published update experiment are required before closing.

[rmcdaniel]

Delivered in Python SDK 2.4.3 through #101, merged source 852981dce65ccb5d1aa4a9050c5d3012cd255cf6.

Accepted handler failures now raise public UpdateFailed with the handler message, HTTP status, original Server response and workflow/run/update/failure IDs. Existing InvalidArgument catches continue to work. Malformed arguments, validator rejection and validation infrastructure failures keep their separate mappings. Both sync and async clients are covered. The public errors reference is deployed.

Source CI, merged-main CI and publication verification passed. Publication verified exact metadata and supported installs. The PyPI wheel SHA256 is ce34a2a80bdc789494738e249aaaa28bd08c9dd4c155967efc01ef6b19f565a1.

Sample App #154 is merged at c3377e18b89ce83838570c81eb4d592200c330e8. The published tuple is PHP SDK 2.2.3, Python 2.4.3, Rust 3.3.0, CLI 2.1.3, Server 2.5.9, Waterline 2.3.1 and Workflow 2.5.3. Server digest: sha256:11c11e11498b63e644d906e43f49810a1bc0b5298f750734fe0edb279c622bca.

Main's actual published update experiment passed all nine PHP/Python/Rust client/handler directions, SIGKILL worker replacement, duplicate successful requests, typed failed duplicates, validator refusal and three original workflow completions. Both failed requests returned UpdateFailed("codec error: update-probe-failure"), HTTP 422, run 01m4cgchn3832phecz8r7tf5sz, update 01m4cgd1k30qd4ey2n02m33z07 and failure 01m4cgd22kxt6s2xhxwdvyntxe. Their recorded acceptance and single failed completion retain those identities. The workflow stayed live and later completed once. All twelve timer cases and ordinary main checks passed too.

Native image publication and qualification passed amd64 and arm64. Independent anonymous registry reads verified both immutable and main images in GHCR and Docker Hub at sha256:704c829151389be0477de946c8cd1457193f041992776af45625f6241666aee5, with both native source revisions matching the merge. Immutable tag: sha-c3377e18b89ce83838570c81eb4d592200c330e8-run-37710305082-1.

Both merged remote branches are deleted and verified absent. Task worktrees and local dependency/tool caches are removed. The published experiment removed its own containers, volumes and images. All acceptance requirements are complete.