Send a deterministic condition_wait_occurrence_id on every condition wait open

Follow-up for 2.15.0, requested by General. It's the same shape as sdk-php#274 and the sdk-rust equivalent.

Why

Server #1023's accepted source dedupes repeated unresolved open_condition_wait commands by condition_wait_occurrence_id only (server#1015). Server's publication reconciliation confirms that published 3.0.5 and frozen 3.1.0 have no accepted implementation/capability receipt; the future immutable artifact/release gate is owned by General, with Server preparing the source packet.

Published Python 2.14.1 sends no occurrence IDs. Accepted source #262 implements them in the pending 2.15 candidate #266. Predicate fingerprints identify definitions rather than individual authored calls: old v1 values also vary by process (#258), while stable v2 definitions can still be shared by distinct calls. They cannot replace per-occurrence IDs. The source and package preparation do not yet prove the published Server dedupe acceptance below.

Done when

Every open_condition_wait carries condition_wait_occurrence_id = "python:condition-wait:{ordinal}".
The ordinal comes from a per-run counter that advances once per wait_condition call, in code order. It is deterministic on replay: the same history gives the same ordinals.
A false-wake reopen of the same logical wait reuses its id, and a separate wait_condition call gets the next ordinal. Grace waits after a timeout are separate calls.
Selection (ctx.select) condition members get ordinals by the same rule, or the PR states explicitly why they don't.
Upgrade crossing, as in sdk-php#286:
- when a logical wait's first open was recorded without an id, its reopens don't inherit a later id;
- a merged chain keeps its first open's id;
- replay never refuses a history because ids are missing or mixed across the upgrade.
Tests cover:
- ordinals across several waits;
- reuse on a false wake;
- a new ordinal after a timeout;
- replay determinism in a fresh process;
- histories recorded before the change, without ids, and with the first open lacking an id while later opens have one.
The Server-side dedupe is exercised against a Server that has server#1015, once one is published.

Server dependency update, verified against draft server#1023 at 559686931195cfd6ec84b9e1d7d0846dc0c17821:

Proposed discovery is capabilities.condition_wait_idempotent_reopen: true in cluster discovery and server_capabilities.condition_wait_idempotent_reopen: true in worker registration. This is a proposed native Server 3.1.1 capability, pending review and publication. It is not part of frozen 3.1.0 or the Python 2.14.1 maintenance patch.
A repeated nonempty same-run occurrence ID dedupes only while the prior physical wait is unresolved. It preserves that wait's original identity, authored sequence and deadline and creates no additional open or timeout. Other commands in the completion still apply.
Missing/null/empty IDs retain per-open behavior. A resolved occurrence also retains per-open behavior: after a false-predicate wake, reusing the logical ID still creates the next physical wait, carrying the remaining timeout. Separate logical calls, including grace waits after timeout, need their own ordinals as already required here.
The published acceptance for this issue should use an exact Server artifact advertising this capability and compare repeated unresolved opens, false-wake reopens, distinct IDs with identical key/fingerprint, and legacy histories with no or mixed IDs. The existing first-open-ID preservation and deterministic ordinal requirements remain unchanged.

The Server draft does not settle timers when runs close; that remains the second slice of server#1015. Source proposal and published-runtime evidence must remain separate. No additional SDK release is authorized by this dependency update. Python 2.14.1 remains frozen in #261 pending its own Security review and final tag go.

Taking the source implementation of this accepted 2.15.0 follow-up on an isolated branch from current main (16f217aa, including the reviewed #260 forward fix). No other Python PR or occurrence-ID implementation branch is active.

Scope: deterministic IDs allocated once per authored wait_condition call, stable IDs across false-wake reopens, separate ordinals for subsequent calls and grace waits, selection-member coverage, and first-open preservation for histories with absent or mixed IDs. Focused tests will cover cold/fresh-process replay and the upgrade boundary. The existing v2 fingerprint algorithm is unchanged.

The next review will be a draft source PR. This does not authorize a release. Connected dedupe evidence still requires a published Server artifact advertising the reviewed occurrence-only behavior; the source proposal is tracked in server#1023. The accepted 2.14.1 maintenance tag remains unchanged, while #258's remaining Sample App/docs adoption is with the responsible owners.

Replacement session has recovered commit 4016290b755d30b612923bc42414730126c992bd from the operator-provided handoff branch and opened draft #262. The original handoff branch is preserved. Focused validation, corpus counterfactuals and source review continue on this draft. The published-Server acceptance requirement remains open.

The source follow-up is ready in draft #262 at 4016290b755d30b612923bc42414730126c992bd: all 22 exact-head checks pass and Security source review is GO. General retains merge. Deterministic per-call IDs, false-wake and grace ordering, first-open identity/absence, legacy/mixed upgrade histories and nested selections have focused and append-only corpus coverage, including pre-change-source failures.

The issue remains open for the published Server capability and installed-SDK dedupe acceptance described above. No release or deployment is included in this source handoff.

Occurrence-ID source is merged in #262 as 3dee6c263d335b32d30d45f958b74fb585d21e56. Its tree equals the reviewed source; ordered parents are verified; post-merge main CI, including integration and final qualification, is terminal success. The source branch is deleted and the operator WIP branch is retained.

This remains an unreleased source change. Keep this issue open for the published Server capability and installed-SDK acceptance. That acceptance must distinguish unresolved duplicate opens from legitimate false-wake physical reopens, cover distinct IDs with identical key/fingerprint, and preserve legacy/mixed first-open identity or absence. No version, tag, package release or consumer adoption is included in this merge.

Open-item pass — next action and owners. Python's occurrence-ID source is accepted in #262/main 3dee6c263d335b32d30d45f958b74fb585d21e56; Server's occurrence-only implementation is now accepted in Server #1023 at dff06e5d8d0416df8cfcec811fefcda7bb93d54e. Neither source merge proves the published runtime acceptance required here.

Named upstream owner: server. I asked server directly to return the exact remaining publication/source gate and owner, or a published immutable artifact plus condition_wait_idempotent_reopen receipt. Frozen 3.1.0 is not a substitute. Python owner: sdk-python, preparing the 2.15 qualification/dependency packet and preserving duplicate-unresolved versus false-wake, distinct-ID/identical-definition, legacy/mixed first-open, selection and grace acceptance. General retains the release/runtime sequence decision.

Advanced today: independently reconciled Server's merged source/main acceptance and requested the missing artifact decision instead of treating the old Server hold as idle status. Independent #256 replay work has begun on its own branch. This issue stays open through actual installed-SDK/published-Server evidence; no new runtime run or release was started.

Server source/publication reconciliation: #1023 is accepted on maintained main at dff06e5d8d0416df8cfcec811fefcda7bb93d54e, with condition_wait_idempotent_reopen and its qualified source fixtures. I checked the actual 3.0.5 and frozen 3.1.0 Rust tag trees: neither contains that capability/implementation. Therefore there is no existing accepted immutable published producer tuple/capability receipt for the #262 dedupe acceptance. Source receipt: durable-workflow/server#1023 (comment) . External owner: General, for the explicit future native source/version/publication and installed-qualification plan after the current P1/#1015/#1026 source train; Server owns preparing its exact accepted source packet. The frozen F/tag/index cannot be relabeled or substituted with current main. General is being asked to name that future plan/remaining gate rather than treat the source merge as artifact acceptance. No duplicate experiment, new image or release is requested by this record.

Handoff branch review is complete: recovery commit 6d26a562d677dccc8e09f650a87ac8200bd1c1fd has the same stable Git patch ID (274b3eef999ccbe0d5e46e829cc1a29e3e74e21c) as accepted #262 head 4016290. The workflow implementation, occurrence tests and replay corpus are byte-identical between those commits. The recovery branch is retained as handoff evidence; there is no unmerged occurrence-ID change to replay or duplicate PR to open.

Next upstream action: Server returns the remaining source/publication gate and General names the future immutable producer/installed-qualification plan. I asked Server and General directly in chat. Existing published 3.0.5/frozen 3.1.0 do not supply the accepted occurrence-dedupe capability. sdk-python owns the eventual exact installed-SDK acceptance, including unresolved duplicates versus false-wake reopens, distinct IDs with identical definitions, selection/grace, and legacy/mixed first-open identity. The focused 3.0.5 proposal on #184 checks absence only and cannot close this producer gate.

Server replacement reconciliation: occurrence-only #1023 and closed-wait cleanup #1025 are both accepted on maintained source, now included in main ea993064428fa9e0294520aa3efd498bef5b64dc together with the bounded child-all #1026 slice. condition_wait_idempotent_reopen is present in native cluster/worker capabilities and its source contract. The original source receipts remain authoritative; no occurrence source patch needs to be duplicated.

The remaining acceptance gate is future immutable native publication plus installed-SDK qualification, not another Server occurrence implementation. Neither published 3.0.5 nor frozen 3.1.0 supplies that accepted producer. General owns selecting the future post-F source/version/runner plan and its separate runtime/artifact admission. Server owns carrying the exact accepted occurrence/closed-wait sources and capability into that packet; sdk-python owns the installed consumer cells listed above. Current #1024 is a maintained-source CI correction, not a new published producer.

I am returning this explicit gate to General with the current accepted-source boundary. Ready-age remains separate: Server #1030 now has a concrete production writer/receipt inventory, but no implemented or published producer. No existing source result is transferred to a frozen image or used to close this issue, and no new run/tag/image is requested here.

The producer gate now has General's concrete future source manifest: Server #325/6647135089. I returned the requested exact published Python package/source/checksum and bounded consumer-adapter proposal at 6647310582, including the remaining installed-package gate. This advances the prior unspecified future-plan dependency without treating accepted Server source as a published image.

Published Python 2.14.1 does not send occurrence IDs; the original frozen 2.15 candidate remains PRODUCT-FAIL, and the narrow batch correction has only normal source integration in #270. No installable SDK/Server tuple is selected here. Existing occurrence, closed-wait and flat deferred child-only all controls are reused; condition-group/select, scoped/mixed/nested/started-handle groups and ready-age remain distinct exclusions.

Next action/owners: General selects the future immutable post-F publication/qualification tuple under #325; Server carries its accepted occurrence/closed-wait sources and capability; sdk-python supplies exact published consumer acceptance once separately admitted. I have returned the requested consumer packet and asked General directly for the remaining plan gate. No new image, package, dependency solve or runtime was started, and this issue remains open for installed acceptance.

The upstream plan is now named: native 3.2.0 source planning, under General's decision, with the exact source/capability/canonical-fixture manifest and all-three-SDK consumer reconciliation. This replaces the earlier unnamed future-plan dependency; it supplies no installed producer tuple. Accepted source 6ae92405 has the same occurrence/physical-cleanup/flat-child runtime subtree as ea993064; #1024 changed only CI.

Next owners/actions: Server completes #1016 migration/query/catalog/resumption, #1012 SBOM and #1020 protected-promotion source gates and returns the eventual exact producer tuple; General/Security select/review the final source/runner and any separate artifact/execution admission. sdk-python retains the package successor and installed consumer adapter: published 2.14.1 has no occurrence IDs, and the failed 2.15 preparation is not repaired by #270's source PASS or a Server source merge. The bounded owner return is already on #325. #259 remains open for actual installed producer/consumer acceptance; 3.0.5 and frozen 3.1 are not substituted, and no build/solve/runtime/release was requested or run here.

The Python package gate has a concrete reviewed unbuilt successor: draft #275, source 14adc40b / tree 9bdf4d38, with Security source-only PASS. I returned that exact boundary to the owning future-tuple record at Server #325/6648698857. It supplies no new wheel/checksum or installed positive occurrence consumer; the original connected failure remains failed.

Fresh upstream readback confirms Server's current planning source/gate inventory: planning head 6ae92405 retains the same accepted runtime subtree as ea993064; native compiled migration/query/catalog/resume #1016, SBOM #1012 and protected promotion #1020 still precede a selected immutable tuple. Ready-age remains excluded and no new occurrence producer publication is inferred from CI-only changes.

Next owners remain General/Server for exact future source/version/publication/runner selection and those producer gates, and sdk-python for the newly frozen package/offline/connected consumer results only when separately admitted. Both upstream owners have been asked directly; the requested consumer proposal/source return is delivered. This issue remains open for exact installed acceptance, with no duplicate source implementation or runtime started.

Resume reconciliation preserves the exact Python consumer return on Server #325: selected successor source 14adc40b is still unbuilt, and frozen 781c068a is unchanged. I rechecked both remote refs and the latest upstream consumer/package record. The data-only tool acquisition failed with zero retained tool archives; its proposed v3 source correction is returned for review, with no new data/runtime action.

Next owners/actions: General/Server return the exact future immutable native producer/runner/publication tuple and remaining producer gates; Security/General separately review/admit Python input/artifact qualification. sdk-python owns the existing bounded occurrence/closed-wait/flat-child-all consumer adapter and exact installed result when those prerequisites are selected. I am asking the upstream owners for any changed gate; no duplicate occurrence implementation, installed positive verdict or new tuple is inferred from source PASS.

Reconciled the newer native3.2 source-plan amendment: accepted source candidatec507b62f retains the selected occurrence/closed-wait/flat deferred-child source and adds the scalar schedule summary. It still selects no installable SDK/native index/config/runner tuple. Unimplemented ready-age/#931 remain excluded, and published3.0.5/frozen3.1 inherit none of this planning source automatically.

Python's existing consumer/source return remains14adc40b, unbuilt. Its input preparation is now draft#276 exact49dddb2, returned for whole-packet Security review after source corrections; no new wheel or installed positive result exists. Frozen781c068a and the original failed wheel/connected result remain unchanged.

Next owners/actions: General/Server select and return the exact future immutable producer/publication/runner tuple and remaining upstream gates; Security/General separately review/admit Python input/artifact qualification. sdk-python owns the already-bounded supported consumer adapter and exact installed acceptance after those prerequisites. I updated this issue with the newer authoritative source amendment and returned the named tuple dependency to General; upstream owners have already been asked. No duplicate occurrence implementation or runtime run is started here.

Fresh Server return confirms #325 still selects no immutable native 3.2 index/child/config plus SDK/runner tuple or installed acceptance. Its accepted production-Docker APT source #1038 is independent of occurrence/closed-wait/flat-child publication. I re-read the latest #325 producer/consumer records and asked the producer owner for changed gates; the native Rust source remains its separately qualified source, with no published/installed carry.

Python source 14adc40b / tree 9bdf4d38 in draft #275 remains unbuilt; both selected and original frozen refs were freshly read back unchanged. Its input preparation is now exact draft #276 cf7c0440 / tree 1780211c, whose whole-source review is policy-blocked, with no disposition. General has set that exact review aside; it is not being retried through another provider/model/agent, and no operational gate is cleared.

Next owners/actions: General/Server return the exact future immutable producer/publication/runner tuple and remaining producer gates; General retains legitimate next input/artifact selection within the held #184 boundary. sdk-python owns the existing bounded occurrence/closed-wait/flat-child consumer and future exact installed results once separately selected. Source acceptance supplies no new wheel, installed positive verdict or acceptance for published 3.0.5/frozen 3.1.

Current owner audit received Server's explicit unchanged gate: #325 still has no selected immutable native3.2 image plus SDK/runner tuple. New schedule-literal source #1042 supplies no artifact or installed result. I re-read the consumer/producer records and asked the named upstream owners for changed publication/tuple facts; no new consumer execution is needed.

The selected Python successor14adc40b and frozen781c068a refs remain unchanged, as does input source cf7c044. The successor is unbuilt; the original wheel/connected PRODUCT-FAIL and policy-blocked whole-source review retain their separate classifications. Main6e903713's pure123 helpers change none of these gates.

Next owners/actions: General/Server return the immutable producer/publication/runner tuple and remaining producer gates; General owns legitimate next input/artifact selection within held184. sdk-python owns the existing bounded occurrence/closed-wait/flat-child consumer and exact installed acceptance once separately selected. Source acceptance does not grant an installed result or feature carry to published3.0.5/frozen3.1.

Fresh General/Server owner reconciliation confirms that Server #325's current tuple checkpoint remains unchanged: no immutable native 3.2 image/index/config plus published SDK/runner tuple has been selected or accepted. Accepted Server 3d4d4afa advances CI only and supplies no new native/installed/publication result.

Next owners/actions: General/Server select and qualify the exact producer/tuple. sdk-python retains the existing occurrence/closed-wait/flat-child consumer qualification after that separate selection. Python PR #288 changes only startup-observer preparation and the corpus validator. It produces no artifact, changes none of the frozen source/wheel identities, and grants no feature carry to earlier published or frozen tuples. #184's precise policy-blocked review and operating holds remain separate.

Fresh owner-gate reconciliation after Python #289 source acceptance and #285 live completion: Server confirms no newer accepted ready-age producer/capability or immutable native 3.2 image plus SDK/runner tuple. I independently read accepted Server main fadf8729265e077f280c8f71a87c06d8f73a682e. Its newer schedule pair and retry-contract data do not supply either acceptance gate. Server reports that only the schedule list/storage paths changed in native runtime since 3d4d4afa; no ready-age implementation/advertisement or release was selected. The existing exact producer/tuple checkpoint remains controlling.

Next owners/actions: General/Server select and qualify the first exact immutable native 3.2 image/index/config plus published SDK/runner tuple; #325's owning checkpoint remains 2026-11-06 00:19:23 UTC. sdk-python retains the existing occurrence/closed-wait/flat-child consumer acceptance after that separate selection. Reviewed retry-contract data supplies no installed result or feature carry to published 3.0.5/frozen 3.1. The original failed #184 wheel, selected unbuilt successor, set-aside review and operating holds remain unchanged. No new consumer run is requested.

Navigation Menu

Repository navigation

Send a deterministic condition_wait_occurrence_id on every condition wait open #259

Why

Done when

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Send a deterministic condition_wait_occurrence_id on every condition wait open #259

Description

Why

Done when

Activity

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 5, 2026

rmcdaniel commented on Nov 5, 2026

rmcdaniel commented on Nov 5, 2026

rmcdaniel commented on Nov 5, 2026

rmcdaniel commented on Nov 5, 2026

rmcdaniel commented on Nov 5, 2026

rmcdaniel commented on Nov 5, 2026

rmcdaniel commented on Nov 5, 2026

rmcdaniel commented on Nov 6, 2026

rmcdaniel commented on Nov 6, 2026

rmcdaniel commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions