Repository navigation
Correct documented workflow duplicate policies to the Server contract #163
Description
Python's public Client.start_workflow docstring tells callers to use duplicate_policy="reject", "allow" or "terminate_existing". The PHP Server start route accepts "fail" and "use-existing". The SDK forwards the supplied value unchanged, so following any of the documented choices reaches a different request contract.
Exact source:
- Python client.py, main
0ed44b85467dd4ff7989e158ffd2f834fdd08485: method documentation and unchangedbody["duplicate_policy"]forwarding. - Server WorkflowController validation, PHP main
7e9cbf2c8a8cbf00a20f0b1fd982ebd6ce6318fb:in:fail,use-existingand explicit validation message. - Python generated client reference renders the client API docstrings.
P2 documentation contract defect. A static AST/request-rule comparison confirms all three documented choices are outside the PHP route's allowed set. No live or normally installed request was sent for this finding, and native parity is unqualified.
Acceptance:
- Correct the SDK docstring and any examples to the actual supported wire choices. Explain default, active duplicate and closed-run behavior from the named supported runtime contract.
- Preserve current runtime behavior; do not silently add
terminate_existing, import another engine's reuse policies or change lifecycle semantics to make obsolete prose true. - Add a focused behavior check of the SDK request shape against supported policy values and qualify ordinary installed-client requests against one named published PHP Server baseline. Include invalid legacy values and current
fail/use-existingoutcomes; preserve originals and side effects. - Explain that a resource-keyed workflow ID coordinates admission, not a global physical mutex that revokes downstream work after termination. Link any broader resource-lock recipe separately.
Metadata search found no existing owning issue for this parameter/documentation mismatch. Registration-name duplicate handling is a different boundary.
Activity
rmcdaniel commentedon Oct 19, 2026
Taking this documentation contract correction. The qualification baseline will
be normally installed Python SDK 2.6.0 and published PHP Server 2.9.5 / Core
2.6.2. Runtime behavior and lifecycle policies remain unchanged.
Source review confirms the omitted policy maps to
fail, anduse-existingreturns only a Pending/Running/Waiting current run. An already closed run is
rejected. Duplicate attempts intentionally record accepted/rejected start audit
events, so the checks must preserve the original run, input, deadlines and
business effects while allowing that documented audit suffix. They must not
incorrectly require the complete history to remain byte-identical.
Next: exercise omitted/canonical/invalid documented values through the ordinary
installed client for active and completed originals, then correct the docstring
and guide using those outcomes. HTTP behavior and native parity are not yet
claimed by this source review.
rmcdaniel commentedon Oct 19, 2026
Candidate #165, exact
f7635dec70c9620ea0988439eca7eed0c1c0d559/ whole2180b2bcb9d93d0ca2bacdae9e49b6ba82e0ad65, now passes:f5771101fc55a3e1e8f8bd572beb1d57f593c05db5e5760f0773f75a96fe7ebb/ Core2.6.2.fail/use-existing. Every one retains one run and one exact int64/null/Unicode business result. Active duplicate statuses are409/409/200; completed duplicate statuses409/409/409; each obsolete policy is422 in both states. The current 409 now raisesWorkflowAlreadyStartedwith the exact workflow ID.StartAccepted/StartRejectedaudit event. Invalid policy requests append none. Three independent fresh invalid-policy IDs remain nonexistent.Counterfactuals are separate: published PyPI2.6.0 passes the same lifecycle checks using its actual generic409 exception, while the typed current-reason assertion fails. The historical mapping and unrelated-conflict controls pass. The first three typed originals stopped at that mismatch; their later assertions did not execute.
Only the duplicate-reason mapping changes runtime behavior. No aliases, termination, lifecycle changes, native qualification or Cloud adoption are introduced. Exact hosted checks, immutable2.6.1 publication/normal installation and deployed portal readback remain pending before closing #163/#164.
rmcdaniel commentedon Oct 19, 2026
Delivered in Python 2.6.1
#165 merged at
150c6f6bc14e3516f75cc615b2f75f093ed84ea1, treede9f5fdf400f45a3be25a08fd27f0cf6fb9ccd9a, identical to the qualified candidate.4d4ab4543813988748d949086af47d8dbb0d8392targets the exact merge. PyPI wheel SHA256:94f55ba59de27719ba487c648894d5231823abbe44dc65231e3b26575cc1b355.use-existingreturns the original; closed duplicates refuse. Obsolete values return 422 without admission or mutation. Canonical duplicates retain their explicit start-audit suffixes.Only the duplicate-reason exception mapping changes runtime behavior. Policy values, admission, lifecycle, encoding and dependencies stay unchanged. The published-client typed failures remain their original failures. Initial local installation/setup failed before business admission; the subsequent normal public-index install and six fresh cases pass. A direct CI-log download timed out, so no full remote-log audit is claimed.
All local test resources, databases, dependencies and raw output are retired; runtime roles exited 0 without OOM. Borrowed images and other owners are protected. The merged remote head is independently 404. Sample's qualified tuple stays separate; Cloud's owner retains adoption. Acceptance for #163 and #164 is complete.