Consume published Workflow 2.0.10 fixes

[rmcdaniel]

Why

Server still pins Workflow 2.0.8. Publishing a Workflow tag does not update that dependency or released Server images. This consumes published 2.0.10, including the missing replayable activity-timeout exception identity from 2.0.9 and native MariaDB backend capability recognition from 2.0.10.

Only the Workflow dependency changes; no API or wire payload shape changes. Unchanged first-party SDKs do not require synchronized version bumps.

Qualification and delivery

• Resolve the exact published package with Composer; only Workflow changes; audit and metadata validation pass.
• Pass Server CI and focused timeout/backend checks.
• Publish the corresponding Server patch image and verify its embedded Workflow identity.
• Run affected published-artifact activity/replay conformance, including the first-party SDK paths, and record the exact tuple/results here.
• Reconcile examples and downstream deployment decisions in their owning records.

Upstream: durable-workflow/workflow#499 and durable-workflow/workflow#500. Workflow's own published-package verification passed for 2.0.10; that is not yet Server conformance evidence.

[rmcdaniel]

Prepared Server 2.3.7 and Helm 0.1.86 in the same PR using the existing source-release generator. The Workflow dependency update passed PHPUnit and MySQL replay/query HTTP CI before release preparation. Generator check and all three source-release tests pass using the published Server 2.3.6 toolchain; the host-only invocation could not run its PHP-dependent case because PHP is absent there. Current-head CI must pass before merge. After publication, verify the installed Workflow 2.0.10 identity in the published image and qualify activity-timeout/replay behavior; a green dependency PR alone is not downstream delivery.

[rmcdaniel]

Merged at efb9ddf; the merge tree exactly matches the reviewed PR head, and every required check passed, including the 12-minute bounded-growth smoke. Immutable tag 2.3.7 is pushed and normal publication is running: https://github.com/durable-workflow/server/actions/runs/34388707618 . Selected follow-up: published-image identity and activity-timeout behavior, plus replay across PHP/Python/Rust using Workflow2.0.10, Server2.3.7, PHP SDK2.0.9, Python SDK2.0.4, Rust SDK2.0.5, CLI2.0.0 and Waterline2.0.2. These are qualification inputs, not a passing result yet. No coordinated version bump for unchanged SDK code.

[rmcdaniel]

Server 2.3.7 and matching Helm 0.1.86 publication completed successfully in run 34388707618. Exact DockerHub image digest sha256:7dfc3e6dca0449b103c4499e88d90dc615ba5c904f848c4f0188f4f7a6161f50 contains Workflow 2.0.10 at 10c5d87 and the concrete ActivityTimeoutException. The published activities experiment passes all 11 scenarios, including timeout, typed failures, restart/result recording, heartbeat renewal, PHP/Python parity and Waterline observation. The initial invocation omitted the container-cleanup handoff flag and therefore failed that runner assertion; corrected execution used the stock handoff settings and its container was removed. PHP/Python/Rust replay qualification is still running. A separate worker-crash plus overall-deadline reproduction found workflow#503; the activity suite does not cover that ordering, so this is not a blanket claim that all recovery paths are qualified.

[rmcdaniel]

Published-artifact replay qualification completed successfully on 2026-09-09, 18:57:59-19:01:17 UTC: 31/31 scenarios passed, no findings, no blocked runtime shards.

• Exact tuple: Workflow 2.0.10, Server 2.3.7, PHP SDK 2.0.9, Python SDK 2.0.4, Rust SDK 2.0.5, CLI 2.0.0, Waterline 2.0.2.
• Server image: durableworkflow/server@sha256:7dfc3e6dca0449b103c4499e88d90dc615ba5c904f848c4f0188f4f7a6161f50.
• Runner: scripts/conformance/replay-published-artifacts.sh at 9bf75131235618ddf92609dd0acca658f761d92f, using published distributions only. The disposable Linux runner had host-network access to its isolated Docker stack.
• PHP and Python: completed-history replay, worker restart, activity/signal/update/saga/version/wait state, query after restart, in-flight signal timing, and code-divergence refusal.
• Rust: side-effect replay after worker restart and version-marker replay after code upgrade. Server: malformed/mutated-history refusal.
• All three SDK shards returned exit 0. The isolated Server/MySQL/Redis containers, network and volumes were removed after the run.

Earlier runner attempts were not counted as passes: the execution environment needed Docker-host network access and Python venv support, and the PHP probe required a pure image digest rather than combined tag-plus-digest spelling. No product code was changed to obtain this result.

Together with the 11 passing activity scenarios reported above, this completes the selected published Server 2.3.7 qualification. The separate newly discovered activity lease/timeout defect is tracked in workflow#503 and fixed by workflow#504; its next patch and downstream rollout are separate from this result.