Repository navigation
Verify installed SDK identity before claiming replay artifact proof #139
Description
The standalone replay conformance command can report a passing, proven installed artifact tuple while attributing execution to the wrong Python SDK version. This is an evidence-integrity defect; the reproduction does not show incorrect workflow replay behavior.
Reproduction
Install the published durable-workflow==2.5.9 wheel into a fresh Python 3.12 environment. Verify importlib.metadata.version('durable-workflow') returns 2.5.9. Then run the installed command with:
python -m durable_workflow.replay_conformance --json \
--artifact-version server=2.6.1 \
--artifact-version cli=2.2.3 \
--artifact-version workflow-php=2.5.12 \
--artifact-version sdk-python=2.5.8 \
--artifact-version waterline=2.10.0 \
--artifact-source server=published_docker_image \
--artifact-source cli=github_release_asset \
--artifact-source workflow-php=packagist_package \
--artifact-source sdk-python=pypi_package \
--artifact-source waterline=packagist_packageObserved on 2026-10-13: exit 0, overall outcome: pass, artifact_versions.sdk-python: 2.5.8, and published_artifact_install_only has status: pass and published_install_tuple_proven: true. The installed Python distribution was 2.5.9. No Server, CLI, Workflow or Waterline installation is required to obtain this report. The command runs an offline synthetic-history shard.
Researched cause and proposal
_published_install_scenario() validates supplied version/source strings and derives the proof booleans from those declarations. It does not compare the declared SDK pin to importlib.metadata.version('durable-workflow'). The caller's value also becomes implementation_identity.version. Existing tests supply a fixed older version and expect installation proof.
Report the actual installed Python distribution identity independently of caller metadata, and reject an SDK-version mismatch. Describe other artifact versions as a declared tuple unless their verified installation receipts are available. A string naming a registry channel is not proof that those distribution bytes were installed. Preserve the distinction between this offline shard and the aggregate runner, which can separately collect installation identities.
Acceptance criteria
- An installed 2.5.9 distribution with a declared 2.5.8 SDK pin fails with an actionable mismatch and records both values.
- Matching declarations succeed and report the actual installed SDK identity.
- Offline success does not claim that other supplied platform artifacts were installed or executed; their declarations remain useful metadata.
- Tests cover mismatch, missing installed metadata and matching identity; aggregate qualification still composes actual verified installation receipts with shard outcomes.
Activity
rmcdaniel commentedon Oct 13, 2026
Confirmed this finding on the current normally installed 2.5.10 package. Declaring
sdk-python=2.5.9still produces overall pass, reports implementation version2.5.9 and setspublished_install_tuple_proven=true. No other product installation is present in this offline container. The relevant module is unchanged between2.5.9 and2.5.10.The correction will read the installed distribution version independently of the declaration, fail missing metadata or a mismatched SDK pin with both identities recorded, and keep the other platform tuple as declared metadata. Offline replay success cannot establish a verified platform installation. Existing scenario identity and replay coverage remain intact; the aggregate runner must continue supplying its own actual installation receipts. No shared Server reader or fixtures will be edited here.
Matching, mismatched, missing-metadata and normal CLI controls will cover the change. The current stable package and Nexus producer cohort remain separate until the fix and affected consumers are qualified.
rmcdaniel commentedon Oct 13, 2026
Fixed in Python 2.5.11, source
170a4abcdc651dd8eee14db53de04f6e23b5a2bf, through reviewed source #140 and stable #141. The offline command records its actual installed SDK version, fails mismatched or missing metadata, and labels other platform pins as declarations. Replay success no longer claims full installed-platform-tuple proof.Complete source CI, independent stable CI and publication/registry checks pass. The new actual command fixture passes candidate/published 2.5.11 and fails normally installed 2.5.10. The corpus guard and existing history fixtures remain unchanged.
Fresh normal installation passes 166 focused tests. Real CLI controls return 0 for matching 2.5.11, 1 for a mismatch and 1 without installed metadata, retaining honest identity and false full-tuple proof. Pinned and unpinned installs select the same wheel. All 33 package files match the release source, installed wheel and registry sdist. Wheel SHA256
7fa32cea7595168d6664feb30420bb9d7215639b4414789c99c078c35ed5762a; sdistc3ad382035c10f339586458b4de47da857caab16e89db3ce532d8f6a2eadf8fc.The first installation stopped at transient index availability before execution and is retained separately; a fresh normal install subsequently passed. The shared aggregate reader already supplies its own verified installation receipts and is unchanged. Client, Worker and workflow files are byte-identical to 2.5.10; existing runtime consumers and frozen tuples need no incidental retuple. Pending Nexus producer work is excluded. All task resources and completed worktrees are retired.