Problem
Condition-timeout timer history is not self-identifying when the internal timer receives a sequence different from the preceding event. The scheduled and fired timer rows can omit both and , forcing an SDK to infer timeout ownership from event adjacency and workflow-generator behavior.
That ambiguity has already allowed an internal condition timer to enter the ordinary workflow-command cursor and produce nondeterministic replay. An ordering heuristic in one SDK is not a durable worker-protocol contract and risks asymmetric behavior across language workers and mixed-version histories.
Acceptance criteria
- Server records a stable condition-wait identity and on the scheduled, fired, and cancelled rows for every condition timeout, including when the timer has its own sequence.
- The public worker-history contract and executable conformance fixtures define this correlation without relying on repository-local paths or event adjacency.
- The change is additive for mixed fleets, and histories written before the explicit fields were added remain replayable.
- Python replay uses explicit identity for current-protocol histories and does not need adjacency-based classification there; any legacy fallback is narrowly bounded to the historical shape.
- Cross-language conformance covers a timed condition interleaved with an update and signals and proves the timeout rows never advance the ordinary activity/timer cursor.
- Published successor artifacts pass the exact-current managed-runtime matrix without nondeterministic replay or an indefinitely waiting workflow.
Delete when
Delete when newly written condition-timeout histories are self-identifying, old histories remain replayable, the current Python path no longer depends on adjacency inference, and published-artifact conformance passes across the supported language workers.
Required source targets
durable-workflow/sdk-python@main
durable-workflow/server@main
Problem
Condition-timeout timer history is not self-identifying when the internal timer receives a sequence different from the preceding event. The scheduled and fired timer rows can omit both and , forcing an SDK to infer timeout ownership from event adjacency and workflow-generator behavior.
That ambiguity has already allowed an internal condition timer to enter the ordinary workflow-command cursor and produce nondeterministic replay. An ordering heuristic in one SDK is not a durable worker-protocol contract and risks asymmetric behavior across language workers and mixed-version histories.
Acceptance criteria
Delete when
Delete when newly written condition-timeout histories are self-identifying, old histories remain replayable, the current Python path no longer depends on adjacency inference, and published-artifact conformance passes across the supported language workers.
Required source targets
durable-workflow/sdk-python@main
durable-workflow/server@main