Skip to content

Define recorded parallel policies and shared history vectors - #378

Draft
rmcdaniel wants to merge 1 commit into
mainfrom
contract/sdk-python-232-parallel-policy
Draft

rmcdaniel wants to merge 1 commit into
mainfrom
contract/sdk-python-232-parallel-policy

Conversation

@rmcdaniel

Copy link
Copy Markdown
Member

Refs #232 and durable-workflow/sdk-python#307.

Existing Python parallel histories wait for all members and choose positional failures; changing that timing globally would break replay. Define an explicit recorded policy so new groups can propagate the first recorded failure while old histories keep their original behavior.

Workflow acknowledged sdk-python's bounded contract/fixture handoff and retains embedded producer ownership. This draft fixes policy placement in canonical member/path metadata, proposes an incremental per-policy capability descriptor, and supplies shared synthetic history prefixes for legacy Python, propagate, cancel-remaining and settle outcomes plus admission refusals.

The policy/capability source requires Workflow and Server review. No runtime capability is advertised. Existing cancellation-command mapping and the settled-outcome envelope remain explicit activation gates for those two policies; this PR does not invent a new command or qualify an installed tuple. Python's applicable legacy fixture is already running through its ordinary replay corpus in the linked SDK draft.

Validation: JSON parses, fixture IDs/paths are reviewable, and public-boundary/normal CI checks remain required. This is a contract/fixture source change, with no production operation or release.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Workflow review of c0607e80ba8bd1c635dc00e96a85ee921ef25fbb: the field placement and incremental per-policy capability shape fit the handoff. Python can continue the disabled explicit-propagate implementation and legacy regression. No runtime support or publication is approved by this review.

Please make three boundaries explicit before freezing the contract/fixtures:

  1. Replacement-worker eligibility. “Both sides support the selected policy” must cover every worker allowed to claim/replay the admitted run, not only the worker that submitted the new group. Require claim/replacement fencing on the persisted policy or an equivalent compatible-cohort restriction. A worker lacking the recorded policy must refuse/block before ordinary execution, with no fallback to legacy timing. Otherwise a cold replacement on the same queue can reinterpret a newly admitted group.
  2. Canonical order in fixtures. The history events currently omit the top-level durable event sequence. Give each event an explicit sequence independent of payload.sequence (the authored operation index), and add a tied-timestamp failure case. The higher-position member must still win when its terminal event is first in durable sequence. Include a later unrelated event so the failure clock cannot accidentally come from the tail. Array position is useful fixture data, but should not be the only representation of the ordering contract being tested.
  3. Policy applicability. State explicitly that a selection frame cannot carry its own parallel_group_policy; a containing all-group's frame may have one. Unknown/present-null policies and inconsistent presence remain refusals before writes. Keep unsupported nested compositions and local/prepared admission disabled as the draft already says.

The deferred cancellation-command mapping and settled-outcome envelope are sensible activation gates. They should not block the propagate-only source work. Server still needs to confirm producer discovery/registration and the actual claim fence before anything advertises support.

@sonarqubecloud

Copy link
Copy Markdown

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant