Repository navigation
Acknowledge pending workflow replay without empty-command completion errors #98
Description
Activity
- added
on Oct 7, 2026 Delivered in PR #99, merged as
2fe5acc9f03664bd5fff5d298849931477247d81, and published as Python SDK 2.4.2. The immutable release tag points to that exact main commit.Exact PR and main CI pass 2,460 unit tests across Python 3.10/3.11/3.12 and 22 connected tests, plus lint, mypy, corpus and package checks. Publication succeeds. The live SDK reference documents the waiting acknowledgement and stream metadata guard. The merged branch is deleted.
A normal PyPI install of 2.4.2 passes the published Server 2.3.12 to 2.5.6 recovery scenario with PHP 2.2.3 and Rust 3.2.0 on protocol 1.19. All nine original completed/waiting/queued workflows complete with identical 204800-byte external payloads and committed history prefixes. After repeated signals and SDK process SIGKILL while timers are still pending, waiting runs each have one scheduled/fired timer and total eighteen. Each run has one activity and workflow completion.
The complete HTTP log has zero HTTP 422s and six successful waiting acknowledgements across 2,765 requests. Python logs have no workflow task completion error. Rust's temporary HTTP 502 exit during replacement is recovered by its normal supervisor. This verifies supervised recovery without promising uninterrupted worker processes. All disposable resources are removed. Nonempty completion parity and configured HTTP timeout tests remain passing. Stream metadata without commands is refused before a waiting request, so it cannot be silently discarded.
- added and removed
on Oct 7, 2026
Observed defect
Published Python SDK 2.4.1 preserves a pending operation during replay, but its client submits
commands: []to/worker/workflow-tasks/{task_id}/complete. Server requires a nonempty command list and returns HTTP 422,The commands field is required.This reproduces with published Server 2.3.12 and 2.5.6: start an echo activity followed by a durable timer, then signal while the timer is pending. Replay correctly retains the original timer, but its task acknowledgement is rejected. The workflow can later complete when the timer fires, hiding the failed acknowledgement in an otherwise successful final result.
PHP already sends empty-command replay through the established
/failacknowledgement with failure typeWorkflowTaskWaitingForHistory. This is a waiting acknowledgement, not a workflow failure. Python should use the same protocol.Required outcome
Found while rerunning the published-package continuity scenario after #96. The scalar replay fix remains correct. This is the additional transport acknowledgement gap its corrected pending path exposes.