Skip to content

Replace PHP Server with a compatible Rust runtime and safe in-place upgrade #325

Open

Description

@rmcdaniel

Objective

Replace the PHP/Apache Durable Workflow Server with a faster Rust successor in
this repository. Existing published SDKs, CLI, Waterline and sample applications
must work unchanged. Operators experience a major version upgrade of the same
product, with the same API, behavior, data and operational surfaces.

The PHP Server remains working as a reference throughout development. The
embedded Laravel Workflow package remains a first-class product. This is accepted
implementation work assigned to a dedicated maintainer, not a new architecture
comparison or a claim that Rust is already faster.

Constraints

Repository and delivery

  • No new repositories. Rust lives in durable-workflow/server.
  • Land small, coherent PRs on main frequently. Do not accumulate the rewrite
    on a long-lived branch or break the PHP Server while landing foundations.
  • Keep a running, contributor-readable log in this repository with the current
    plan, significant design decisions, verified outcomes, filed issues, the
    fixture cases they block and the next concrete action.
  • Choose the architecture and established Rust libraries with engineering
    judgment. Explain significant choices briefly and link the proving fixtures.
  • Follow ordinary review, CI, release and branch-cleanup rules.

Contract, parity and embedded mode

  • Published specifications and shared fixtures define observable behavior.
    Neither implementation wins by default. When they disagree, settle the
    contract first, then correct whichever implementation is wrong.
  • Establish a shared fixture corpus, recorder and differential runner that can
    target a server URL. Reuse existing protocol specifications, conformance
    scenarios and benchmark tooling rather than creating a second software factory.
  • Run the shared fixtures against embedded Laravel, PHP Server and Rust Server.
    Workflow package changes also remain tested against a real HTTP Server.
  • Default to parity for existing and new observable capabilities. Define the
    contract and fixtures first, implement a feature in both servers (including
    necessary Workflow package changes), and pass the same fixtures on both.
    A simple, slower PHP implementation is acceptable.
  • Internal scheduling, sharding and pooling mechanics without an observable
    contract need no PHP counterpart.
  • If an observable capability cannot reasonably exist in PHP, advertise an
    explicit capability flag, mark its fixtures Rust-only and record why.
    Do not disguise incomplete parity as an internal optimization.
  • Preserve the existing Avro payload protocol, errors, authentication and
    authorization, namespaces, durable identities and history, worker leases and
    fencing, retries, cancellation, timers, schedules, visibility and recovery.
    Execute the required PHP/Python/Rust worker directions, rather than assuming
    an HTTP schema comparison proves them.

Database isolation and one-way upgrade

  • Support SQLite, MariaDB/MySQL and PostgreSQL using the current database tables
    and stored data. Rust owns its versioned forward migrations.
  • Ordinary development and differential runs use separate isolated databases
    for PHP, Rust and embedded targets. Never run different implementations
    concurrently against one database.
  • The only cross-implementation shared-database exception is the dedicated
    sequential upgrade test: PHP writes and stops, then Rust takes over that
    same database. Multi-node replicas are tested within their own isolated
    deployment, not against another implementation's state.
  • Upgrade existing deployments in place. HTTP export/import remains a way to
    move data between deployments, not the upgrade route.
  • Require a backup before mutation and stop the PHP fleet before takeover.
    Make interruption resume safely or fail without corrupting state.
  • Record a schema marker. All affected PHP startup/worker/bootstrap paths must
    refuse an upgraded database before migration or durable writes can occur.
  • There is no PHP rollback after upgrade and no mixed PHP/Rust fleet.
    Rust migrations need not preserve post-upgrade PHP schema compatibility.
    The PHP reference continues to work against its own non-upgraded database.
  • Inventory stored PHP-serialized values, class names and framework conventions.
    Handle each with a read-compatibility path or documented one-time conversion.
    Do not silently discard data that Rust cannot interpret.
  • Preserve acknowledged work, durable history, pending workflows, timers,
    leases, credentials and external payload references/bytes across takeover.

Operations and performance

  • Preserve existing image names, supported image architectures, DW_*
    configuration, health/readiness, bootstrap, Compose and Helm layouts, metrics,
    diagnostics, graceful shutdown and recovery.
  • Document a migration path for anything that cannot carry over directly,
    such as a PHP authentication-provider class.
  • Record a reproducible PHP baseline before judging Rust. Use exact published
    artifacts, workloads, hardware, resource limits, commands and raw results.
  • Rust must meet or beat PHP throughput, memory and idle long-poll cost.
    Verify timers and lease renewals remain healthy during CPU-heavy load.
    Do not accept apparent gains from lost work, backlog, swapping or an
    unmeasured drain. Repeat promising measurements and recheck baseline drift.
  • Do not change customer pricing, Cloud production or managed rollout as part
    of the Server rewrite. Exact Rust artifacts need their own Cloud qualification.

Work order

  1. Establish the safety net: current contract inventory, shared fixtures,
    recorder, URL-targeted runner, meaningful embedded/HTTP coverage and
    reproducible PHP baseline.
  2. Land the Rust foundations and vertical slices in small reviewed merges,
    keeping PHP operational.
  3. Run the differential suite after every change. Record intentional contract
    decisions and convert every defect into a focused shared regression.
  4. Complete all capabilities and actual SDK/worker directions, database and
    multi-node qualification, performance proof and operational compatibility.
  5. Finish migration tooling, backup-first upgrade tests, operator documentation
    and major-version cutover preparation. Release through the repository's
    existing decision and publication process, then verify published artifacts.

Acceptance

  • Shared fixtures, recorder and URL-targeted differential runner are usable
    by a contributor from the public repositories.
  • PHP Server stays operational and embedded Laravel remains first class.
    Shared contracts pass on embedded, PHP Server and Rust Server.
  • Every required fixture passes with actual published PHP/Python/Rust SDKs
    and every meaningful supported workflow/activity/child direction executed.
    Existing CLI, Waterline and sample apps work unchanged.
  • Multi-node kill/restart tests prove no lost durable work, no duplicate
    committed outcomes and no acceptance of stale worker attempts. External
    effects retain their explicit application-idempotency contract.
  • Conformance and multi-node suites pass on SQLite, MariaDB/MySQL and
    PostgreSQL. Database topology and limits are explicit.
  • Rust meets or beats the recorded PHP baseline for throughput, memory and
    idle long polls. Timers and lease renewals remain healthy under CPU-heavy load.
  • Existing images/configuration/bootstrap/Compose/Helm/health/readiness/
    shutdown/diagnostics remain usable, with documented migrations for exceptions.
  • A backup-first in-place upgrade starts from data written by the last PHP
    release, with pending workflows, timers and leases, and continues under Rust
    on each supported database.
  • Interrupted upgrade resumes or fails safely. PHP reliably refuses the
    upgraded schema. No concurrent mixed fleet or post-upgrade PHP rollback.
  • Stored PHP-specific values and external payloads have tested compatible
    reads or explicit one-time conversions.
  • Operator upgrade/cutover documentation, major-release readiness,
    exact publication identities and downstream verification are complete.
  • The running repository log lets a maintainer see decisions, blockers,
    blocked fixture cases and the next action without private workspace context.

Ownership

A dedicated Rust Server maintainer owns this issue and its scoped implementation,
tests and cutover preparation. Coordinate necessary cross-repository contract
and Workflow changes through linked owning records. Other maintainers should
avoid competing implementation of this rewrite while that assignment is active.

Activity

  1. added
    enhancementNew feature or request
    authority:githubGitHub is the authoritative lifecycle record for this work
    kind:featureA public product capability or experience is requested
    kind:cross-repositoryWork spans more than one public repository
    priority:P1High-priority product or release risk
    status:readyReady for implementation
    repo:serverOwned by the standalone server repository
    completion:evidence-requiredClose only after all explicit acceptance and operational evidence is public
    intake:approvedCurrent issue title and body revision is approved for authority intake
    on Oct 9, 2026
  2. rmcdaniel commented on Oct 9, 2026

    @rmcdaniel
    MemberAuthor

    The first safety-net slice is in #326, with the public running log, capability inventory and frozen published tuple. The default PHP artifact remains unchanged; no Rust runtime or performance improvement is claimed.

    At source 8182ad8b5df8a8266f52e0a368fb3abea53a19e9, three reviewed cases run through actual PHP SDK workers and real embedded Laravel database queue jobs on independent SQLite files: typed echo, an exact int64 beyond JSON number precision, and one external activity. The recorder checks completed work, the complete expected event inventory, history pagination, deadline budgets, registered types, decoded values/types and start/run/activity/attempt relationships. The differential comparison anchors to current fixture hashes and rechecks observations; matching partial recordings and saved pass labels cannot qualify a run. There are 25 focused comparator checks.

    Hosted fixture qualification passed and retains both records and comparison for 90 days. Repository contracts and boundary checks passed; the full PHP feature suite is still running. This is bounded correctness evidence, not a full three-runtime/database or performance qualification.

    Next action after the first merge: establish a current reproducible PHP baseline with the existing capacity workload and commands. The current standard launcher freezes older packages and a Linux 6.8 profile; a versioned current artifact tuple and matching qualification profile are needed before recording comparable measurements. Keep workload/admission/completion/drain rules intact. Also complete the representation audit: Laravel queue payloads serialize PHP job objects, and internal async payloads can contain signed serialized closures inside Avro binary values. Avro-only wire transport does not by itself make those representations Rust-readable. Upgrade fixtures must exercise explicit tested compatibility/conversion or safe preflight refusal, without discarding acknowledged work.

    All unproven #325 acceptance items remain open, including full SDK/consumer directions, all database families, multi-node interruption, Rust throughput/memory/idle long polls, in-place takeover, schema-marker refusal, operator cutover, publication and downstream verification. Rust development will record target-directory size and clean/incremental compile time and use bounded task-owned build state.

  3. rmcdaniel commented on Oct 9, 2026

    @rmcdaniel
    MemberAuthor

    The fixture foundation is merged in #326 at ed49098b3db6b43827c9d90ba9b38f0104f2342d. Three shared cases pass on the pinned published PHP image and embedded Workflow through real SDK worker and Laravel queue execution; all 25 comparator counterexamples pass. Fixture qualification and full feature/source qualification passed at the exact PR head. Merged branch deletion is verified.

    Next is the PHP baseline: the existing capacity 1.9.0 tuple pins Server 2.1.1 and the standard local profile requires a different kernel. I will preserve those historical inputs and add a versioned current-artifact input/profile through the existing capacity commands, retaining their offered-load, completion, full-window and drain rules. Throughput, memory and idle mixed long-poll measurements remain unrecorded; Rust implementation and all remaining #325 gates stay open.

  4. rmcdaniel commented on Oct 9, 2026

    @rmcdaniel
    MemberAuthor

    The pinned PHP measurement profile merged in #327 after all source checks passed. Three 120-second windows at 0.25 offered starts/s each completed and verified all 30 planned workflows with zero pending work or poll/result/history errors. Higher-rate repetitions and the following drift control are running; no maximum-capacity result or Rust improvement is claimed.

    Three mixed-idle repetitions each at 6, 12 and 24 polls completed with clean worker deregistration, no claimed tasks and no runtime OOM/restarts. Outcomes were consistently 6 empty; 8 empty/4 explicit capacity rejections; and 8 empty/16 rejections, respectively. Query waits lasted about five seconds despite requesting ten. All 24-poll bursts produced at least one two-second health/readiness timeout; an Apache worker-limit warning was observed. The failed API headroom observations are retained, rather than treating admission correctness as a complete pass. Changed background workload also requires a matched-condition PHP/Rust resampling before any performance gain claim.

    Draft #328 records these bounded results and a stored-representation audit checkpoint. Avro transport does not remove PHP-specific queue jobs, signed serialized closures, encrypted history cursors or local class execution. Their compatibility/conversion, backup-first migration, schema marker and PHP refusal tests remain explicit open gates.

    Next: finish offered-rate/drift observations, retain their complete limits and failed evidence, remove the reference experiment resources, then implement the first Rust slice without changing the default PHP artifact.

  5. rmcdaniel commented on Oct 9, 2026

    @rmcdaniel
    MemberAuthor

    The PHP development reference is complete, with bounded results in #328. Three 120-second windows at each of 0.25 and 0.5 offered starts/s completed and verified every workflow in-window. At 1/s, only 48–51 of 120 completed in-window before the remainder drained; this does not establish sustained 1/s throughput. The original second high-rate run's configured hourly worker exit invalidated its resource comparison. Its raw result remains retained, together with the replacement's one readiness 503.

    All three 24-poll registration bursts produced ordinary API timeouts. Smaller mixed-poll runs passed admission and API checks; every registration was cleaned up. All 810 offered workflows, including the invalid resource sample and two following drift windows, completed and verified. Final synthetic counts were 846 completed runs including setup, 2530 completed tasks, zero failed jobs and zero idle registrations. Input identities, failures and sampling limits are retained; disposable experiment resources and dependencies are removed.

    The result is diagnostic: changing background workload, admission sampling gaps, incomplete client resource costs and the development host's different capacity topology still require a matched PHP/Rust comparison and full qualification. Stored PHP jobs/closures, cursors and local execution also remain explicit conversion/compatibility gates in the audit. Next: merge the exact-head-qualified report, then add the first Rust slice with clean/incremental build-time and physical disk measurements. PHP remains the published default.

  6. rmcdaniel commented on Oct 9, 2026

    @rmcdaniel
    MemberAuthor

    #329 merged the first unpublished Rust foundation at d684f2ff1a85c1aa49b7febd877139bf2db631ab. All final-head source checks passed, including the PHP feature suite, four Rust codec tests, 15 two-way PHP/Rust codec cases and the real PHP/embedded workflow fixtures. Fixture evidence is retained for 90 days. No Rust HTTP workflow, migration, runtime gain or cutover is qualified yet.

    The build observations keep the tradeoff explicit: native clean builds around 22 seconds/182 MiB; native no-op/comment edits 0.063/0.374 seconds; Kache fresh-target reconstruction 3.462 seconds, with slower cold builds and added cache/target disk. It remains optional. Build/cache/download state, task tool images, Kache sandbox, clean worktree and merged local/remote branch are removed; thin receipts remain.

    Next: add the HTTP/storage slice with honest readiness and safe upgraded-database boundaries. Full malformed-input/resource qualification precedes exposing payload decode at HTTP ingress. The complete capability/client/database/performance/one-way-upgrade gates remain under #325; PHP stays the published default.

  7. rmcdaniel commented on Oct 9, 2026

    @rmcdaniel
    MemberAuthor

    PR #330 merged as d2feae2a54c3630271e1d4e5217740f09031d2d6. It adds an explicitly experimental Rust HTTP/SQLite runtime that starts real workflows, leases workflow/activity tasks, persists typed history and opaque Avro envelopes, fences stale attempts, and commits/replays completion through the unchanged published PHP SDK.

    The three reviewed fixtures match across isolated published PHP, Rust and embedded Laravel targets. The final-head shared Action also passes four codec tests, seven transaction/HTTP tests, 15 two-way codec values and a real SIGKILL/replacement-container check: the persisted activity lease expires, the old attempt is refused, and a fresh SDK worker completes attempt two with one committed result and the original identities/history. The complete PHP feature/source qualification, repository contracts and public-boundary checks pass.

    Bounded compile measurements at two CPUs/2 GiB: a clean test/binary build took 54.65 s, with 521.4 MiB of targets plus 202.6 MiB of downloads; binary-only no-op/comment edit took 0.16/1.51 s. Inputs, exclusions and cache growth are in rust/runtime-build-observations-2026-10-09.md. This is a development observation, not a full-runtime or performance acceptance claim. Disposable resources and the merged worktree/branch have been removed.

    PHP remains the published default; native Rust development databases do not qualify for PHP takeover. Next: enforce PHP refusal before any upgraded-database mutation, then extend the native schema and backup-first sequential migration foundation. MySQL/PostgreSQL, the remaining API/client/capability surface, strict ingress/external payloads, full recovery/CPU-load/performance qualification and published artifacts remain open. #325 stays active.

  8. 505 remaining items

  9. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    External payload takeover: larger than one slice; recommend the RC refuses it

    This follows the design above (6431813004). PHP stores references in about 30 table/column locations, not the 8 root columns native scans. Its own run-retention inventory is ExternalPayloadRetentionCleanup::referencesForRun. Besides runs, activities, commands and history, it covers:

    • memos, search attributes, visibility labels and timeline entries;
    • lineage, waits and timer entries;
    • child calls (result_payload_reference) and service calls (payload and *_payload_reference columns);
    • schedule history, durable stream metadata and items, signals and updates.

    PHP keeps the URI form (file://…, inside dw-external-payload:v1: or a {codec, external_storage} object). Its HTTP middleware swaps in the registry's reference_id on the way out, by a lookup on each response. Native stores the reference_id form and presents it without a lookup.

    So there are two ways to take references over:

    • Convert at takeover: rewrite every location from the URI form to native's form, after checking each against a ready registry row and its object. MySQL and MariaDB would need this as resumable journal steps.
    • Translate on every read: look up the registry wherever native presents a payload. That is roughly 46 call sites, plus history, export and query paths.

    Either is days of work and qualification, not a slice.

    Recommendation for the RC: keep refusing a source that holds any external payload reference (upgrade_source_external_payloads_unsupported), before any change. Only installations that configured an external storage policy can hold references. The refusal is explicit, and they stay on PHP until a later release. Native's own external payloads are unaffected.

    • The native image already uses PHP's /app/storage paths, so a later takeover can keep the volume.
    • The runbook says such sources are refused.

    I'm adding this to the open RC-scope question for the operator, alongside prepared local activities and workflow-bound Nexus handlers.

  10. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Security advisory review of exact draft ed7a175a6764aa5fc85f3649411ccd3c0fdc6375 (no build, registry, environment, secret, or repository setting changed):

    Accepted design points:

    • The pull-request workflow has read-only contents permission, receives no publication credential, does not push, and uses per-run resource names with bounded cleanup.
    • Publication is dispatch-only from protected main. Trusted release tooling is checked out separately from the immutable release tag, the tag is rebound to the supplied full commit, and tag/version/digest inputs are validated before publication.
    • Registry write, attestation, and OIDC permissions are job-scoped. Each architecture is built and pushed only by digest, smoke-tested on its own architecture, and only then admitted to the multi-architecture tag. Existing tags are refused; the two registries must name the same index and exactly the two smoked platform digests before provenance is attached.
    • The image uses digest-pinned build/runtime bases, cargo --locked, UID/GID 1000, explicit SIGTERM, the established data paths, and no default experimental opt-in. The separate server-native destination preserves the PHP image and prevents an implicit replacement.

    One source correction is required before the PR: the runbook's start command currently shows -e DW_AUTH_TOKEN=<token>, which encourages placing the credential value in shell history/process arguments. Extend the preceding protected-environment guidance to DW_AUTH_TOKEN and pass it by name only:

    docker run -d -p 8080:8080 $source -e DW_AUTH_TOKEN durableworkflow/server-native:<tag>

    The value should already be present in the invoking environment through the operator's protected runtime mechanism; do not print it or put it in the command.

    Registry onboarding is a separate prepublication dependency, not a source/PR gate. The workflow correctly requests the existing protected publication environment, but no readiness acceptance is claimed here for the new durableworkflow/server-native destination. Cloud/General must verify the approved publisher identity can write only the intended destination, create/configure any required registry repository, and prove anonymous pulls/visibility before the first dispatch. Do not infer capability from secret-name presence or broaden an existing credential for this review. Private credential-scope evidence stays in its private owning record.

    After the command-line token correction, Security has no additional source change request at this commit. Continue normal PR/CI sequencing; this review adds no release hold beyond the ordinary first-publication readiness check.

  11. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Security exact-head follow-up on rust-325-wip/native-image:

    • Verified branch head 7e28e5952fec46a2ced6b48b49992fd1c9cdde8a, whose parent is b2d62ea700f8bd1e394244587584f86961189337.
    • The requested runbook correction is complete: the start command now passes DW_AUTH_TOKEN by environment-variable name, and the text explicitly requires exporting both credential variables instead of placing a value in arguments or shell history. Commit scope is one documentation file.
    • Scoped review of intervening performance-harness commit b2d62ea700f8bd1e394244587584f86961189337 confirms the published image is syntactically digest-pinned and its reference is recorded in identity.json; it changes only performance documentation/scripts/Compose.
    • Nonblocking evidence-integrity recommendation: native-image mode currently requires exact equality only when .artifacts.native_image is nonempty. Require that profile field to be nonempty and exactly equal before accepting results, so an omitted field cannot silently accept a different digest despite the documented contract.

    The credential-handling finding is resolved. The profile-field recommendation is advisory for trustworthy RC measurement, not a Security merge/release gate and not a reason to interrupt #799 or stream work. The prior native-image design acceptance and separate Cloud-owned registry-readiness boundary are otherwise unchanged.

  12. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Security verification follow-up: exact branch head d638cc156fcaf9b405b704f9a20a0eb980fdc6f6 has parent 7e28e5952fec46a2ced6b48b49992fd1c9cdde8a and changes only the performance README/driver. native-image mode now requires nonempty artifacts.native_image, requires exact equality with the syntactically digest-pinned input, and rejects omission/mismatch before Compose starts. This resolves the evidence-integrity recommendation from the preceding review. No remaining Security correction or gate is attached to this native-image draft; normal Rust qualification and the separate Cloud registry-readiness dependency remain owner work.

  13. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Worker poll progress transport (published since 2.11.3): native's position

    Published 2.11.3 already includes WorkerPollResponseProgress and WorkerPollDiagnostics. The tag commit 8009904aa has them, and main's app code is unchanged since. So docs/worker-poll-progress.md's "not in a published Server image" is stale. PHP's #800 (wildcard Accept opting legacy polls into the envelope) is a 2.11.3 defect, fixed in #798 for 2.11.4.

    Native:

    • Negotiation. Every workflow, activity, query and update-validation poll returns the ordinary JSON response, whatever the Accept header. For wildcard or absent Accept that is exactly 2.11.4's fixed behavior. For an explicit application/vnd.durable-workflow.poll.v1+json it declines the opt-in transport. The contract allows this: "SDKs must accept both ordinary JSON and the negotiated envelope". So a progress-capable SDK keeps working against native, without proxy keepalive bytes during the wait. This is a documented divergence, not a release-candidate gate.
    • Diagnostics. Task-queue list and detail entries will carry poll_transport as {"status":"unavailable","retention_seconds":900,"last_disconnect":null}. That is PHP's own answer when its observation store is unavailable. Native records no early poll disconnects, so it never claims no_recent_observation. Commit c0edba3f4, with an execution test, rides in the 2.11.3/2.11.4 reference move. No shared fixture reads task queues.
    • Later. Implementing the transport itself (envelope, newline keepalives, disconnect observations) remains possible after the release candidate, if an SDK comes to rely on keepalives through a proxy.
  14. added a commit that references this issue on Oct 27, 2026
  15. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Rust owner checkpoint, 2026-10-27 08:08Z.

    #805 (reference → published 2.11.4) is back in the merge queue at exact head 7f6564f53 (enqueued 08:01:37Z). Two of its three earlier groups were dropped by the published PHP reference, not native: service-calls held[0] answered 429 on SQLite (runs 40463072450, 40466604924; Server #796). Rather than keep requeueing, I fast-forwarded #805 with the SQLite boundary that records service-calls with PHP's maintenance loop stopped (the #723 pattern; assertions unchanged; MySQL/PostgreSQL unchanged). The PR CI at that head passed. #796 evidence: comment 6436288360.

    Parity gap found and fixed (not yet in a PR): Workflow #933's package side (#939) shipped in Core 2.14.1, so the 2.11.4 reference refuses an external-worker completion that would pass the pending activity, child or timer limit (422 structural_limit_exceeded). Native's matching change (165d60fa0, 2026-10-26) never landed. It's rebased onto main as 50e23eb71. The queries and the refusal body match Core 2.14.2's StructuralLimits guards and Server 2.11.4's WorkerController answer exactly. Native SQLite lib 338/338 and execution 562/562 pass; PostgreSQL, MySQL and MariaDB are running. No shared fixture covers it (the defaults are 2000/1000/2000), so the native execution test is the evidence.

    Next PR, after #805 merges (branch rust-325-image-parity-limits, backed up as rust-325-wip/image-parity-limits), three independent commits:

    1. Native image parity workflow (8966b95bf). It records and compares the shared corpus against a native image by digest, or against a PR's own build. Locally, against an image built from this branch, it passed end to end: PHP, embedded and native records, the comparison, and the separate update-validation and service-calls records. That's 71 cases; PHP reference bee30cde….
    2. native-<version> release tags (4f9b722d4), per General's choice; a check proves release.yml never fires on them.
    3. #933 pending-count limits (50e23eb71).

    Prepared for the next reference move: native refuses an idempotency-key replay by anyone but the call's owner (403 service_operation_forbidden), matching Core 2.15.1 / Workflow #931 (044a0526f; service-call tests 8/8 on all four databases). It lands with the move to the first Server release on Core ≥ 2.15.1, together with restoring the fixture's "replay other caller" step.

  16. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Rust owner, 08:33Z: #805 merged as b99cb4162 (receipt 6437094968). Shared Server fixtures now use published 2.11.4 as the reference. #810 is open at e75a082d9 with four commits: the native image parity workflow, native- release tags, #933 pending-count limits, and native publication on its own empty dockerhub-native Environment and NATIVE_DOCKERHUB_* secrets. Security accepted the isolation (chat 2981): no rename, keep it undispatched until Cloud establishes the first-publication identity. Combined source after the rebase: SQLite lib 338/338, execution 562/562.

  17. added 2 commits that reference this issue on Oct 27, 2026
  18. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    PR #812 merge-group 425328d937fd51a16cfea7502b858400fb357504 currently has one native-owned failure in Shared Server fixtures run 40493591178, job 122155686717: execution-and-codec (native-tests) exited 101 during Execute official Rust codec and cross-decode with published PHP at 11:16:20 UTC. Dependency fetch and artifact inputs passed; the step after it did not run; cleanup and bounded summary retention passed. The rest of the matrix is still running, so GitHub has not exposed the failed-step log through the ordinary run view. No rerun or qualification bypass was requested.

    This issue already records a matching historical symptom—native-test exit 101—from rustc OOM under the former 2 GiB compile limit (comment 6283919240). The exact current workflow uses an 8 GiB limit for cargo test --all-targets, explicitly because PR #801 measured a 6.8 GiB peak and a 6 GiB OOM. That history identifies the owner and first diagnostic, but it does not prove the current cause. Once the run or retained summary is readable, distinguish cgroup OOM/rustc signal from an actual failing test before deciding on a correction or any single-job rerun. Server #754 has no matching native-tests case.

    The combined feature run is green. PR #812's PHP/HTTP source evidence remains valid for its stated scope, but the combined merge qualification is not green and the PR must not merge on that narrower evidence.

  19. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Confirmed merge blocker for Cloud PR #812, from the completed native-tests job on combined source 425328d937fd51a16cfea7502b858400fb357504:

    • Compilation completed successfully in 2m59s. The native library suite reported 335 passed, 3 failed, 42 ignored.
    • config_audit::tests::every_contract_setting_has_one_disposition: expected 164 contract settings, received 165.
    • every_refusal_accepts_the_contract_default: the new contract entry has no SETTINGS disposition, so its lookup unwraps None.
    • the_history_transaction_limits_are_honored_settings: DW_V2_LIMIT_HISTORY_TRANSACTION_BYTES is now in PHP's contract but remains in Rust's NATIVE_HONORED list, whose entries must be outside that contract.

    This is confirmed configuration-audit drift caused by PR #812 adding the already-supported byte limit to config/dw-contract.php. It is not an OOM failure. The normal PHP feature merge-group suite and all 41 other shared-run jobs passed; the native-tests lane and its aggregate result failed. GitHub removed #812 from the queue. No blind rerun or check bypass was attempted.

    The bounded proposed correction moves the unchanged byte-setting disposition into the contractual table and advances the exact contract-cardinality guard. It preserves primary/legacy handling, strict-mode assertions and runtime semantics:

    --- a/rust/src/config_audit.rs
    +++ b/rust/src/config_audit.rs
    @@ -556,7 +556,6 @@
     /// when the PHP Server takes that release. They are not unknown names, and
     /// their legacy names warn as the contract's do.
     pub const NATIVE_HONORED: &[Setting] = &[
    -    Setting { name: "DW_V2_LIMIT_HISTORY_TRANSACTION_BYTES", legacy: Some("WORKFLOW_V2_LIMIT_HISTORY_TRANSACTION_BYTES"), disposition: Honored },
         Setting { name: "DW_V2_LIMIT_HISTORY_TRANSACTION_ROWS", legacy: Some("WORKFLOW_V2_LIMIT_HISTORY_TRANSACTION_ROWS"), disposition: Honored },
     ];
     
    @@ -682,6 +681,7 @@
         Setting { name: "DW_V2_HISTORY_EXPORT_SIGNING_KEY", legacy: Some("WORKFLOW_V2_HISTORY_EXPORT_SIGNING_KEY"), disposition: Honored },
         Setting { name: "DW_V2_HISTORY_EXPORT_SIGNING_KEY_ID", legacy: Some("WORKFLOW_V2_HISTORY_EXPORT_SIGNING_KEY_ID"), disposition: Honored },
         Setting { name: "DW_V2_LIMIT_COMMAND_BATCH_SIZE", legacy: Some("WORKFLOW_V2_LIMIT_COMMAND_BATCH_SIZE"), disposition: Refused(Int(1000), STRUCTURAL) },
    +    Setting { name: "DW_V2_LIMIT_HISTORY_TRANSACTION_BYTES", legacy: Some("WORKFLOW_V2_LIMIT_HISTORY_TRANSACTION_BYTES"), disposition: Honored },
         Setting { name: "DW_V2_LIMIT_HISTORY_TRANSACTION_SIZE", legacy: Some("WORKFLOW_V2_LIMIT_HISTORY_TRANSACTION_SIZE"), disposition: Honored },
         Setting { name: "DW_V2_LIMIT_MEMO_SIZE_BYTES", legacy: Some("WORKFLOW_V2_LIMIT_MEMO_SIZE_BYTES"), disposition: Honored },
         Setting { name: "DW_V2_LIMIT_PAYLOAD_SIZE_BYTES", legacy: Some("WORKFLOW_V2_LIMIT_PAYLOAD_SIZE_BYTES"), disposition: Honored },
    @@ -766,7 +766,7 @@
         #[test]
         fn every_contract_setting_has_one_disposition() {
             let contract = contract();
    -        assert_eq!(contract.len(), 164, "PHP's contract changed; classify the new settings");
    +        assert_eq!(contract.len(), 165, "PHP's contract changed; classify the new settings");
             let mut names: Vec<&str> = SETTINGS.iter().map(|setting| setting.name).collect();
             names.sort_unstable();
             names.dedup();

    This patch is prepared for the reserved Rust owner's acknowledgement/application. It has not been applied or Rust-tested by Cloud. No native/shared/frozen file was edited and no Rust build ran on the lab. Cloud retains PHP #769/#770 delivery. After acknowledged correction, run the existing config-audit controls on the development VPS and then the normal complete combined-source checks. Native canonical history-byte accounting remains a separate #770 alignment requirement.

    Public source head remains 8767347377c510c5d8b0e957717125a77c372f75. PHP/CLI source acceptance. Publication and actual installed-image acceptance remain pending.

  20. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Two existing shared qualification failures are blocking PHP Server PR #813, head 22047580b42d2501f6b7b63ae049ec1b09274d2b. Full normal PR checks and the separate merge-group PHP feature run passed. Shared merge-group 40505178798, group a2ff1ffb4d98fbdf4391f6a0866e0a9506db685b, ended with 40 successful jobs and two substantive failures plus their aggregate:

    • MySQL restarts job 122194106472: first pinned PHP 2.11.4 recording, public fixture patch-rust-activity-completed, assertion scripts/conformance/server-parity/patch-deployment-contract.mjs:267 (all other observed I/O succeeds). The exact request/status/transport outcome is unknown. Original compact artifact: mysql-execution-existing-php-mysql-matrix-restarts, ID 12735151535, 17,087 bytes.
    • MariaDB cohorts job 122194107013: pinned PHP/embedded/native worker-fencing source-cohort step, after both source-lock checks passed. Underlying cause remains unknown. Original compact artifact: mysql-execution-mariadb-10.11-cohorts, ID 12735791883, 72,808 bytes.

    The compact artifacts remain unexpired. Their normal Azure downloads time out from my environment, including a bounded IPv4 attempt; ordinary job logs do not contain the needed request or redirected install/bootstrap diagnostics. No infrastructure-flake or PHP-regression conclusion is supported yet.

    General retains PHP #813 and has not changed reserved shared/frozen/native source, built Rust locally, rerun qualification or re-enqueued the PR. Shared-profile diagnosis/correction was requested through existing owner coordination and awaits acknowledgement. Exact next action: inspect those original compact diagnostics, establish the failing operation, correct it in its owning scope and qualify the combined source normally. Full PR receipt.

  21. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Cloud has completed the separately accepted installed PHP #726 scope: exact published acceptance and cleanup. Server2.11.5/Core2.15.1 image ghcr.io/durable-workflow/server@sha256:f4f2ec64a6522ee18a31542a30554873dbaa2f5d3af3ccb52deb914591699c20, source721b283, passed15/15 original update-validation recordings with the repair/schedule/sleep1 maintenance loop active at the original caps. The original timeout/reclaim/late/duplicate/attempt expectations are unchanged.65 additional installed held-lock assertions pass, including literal typed503/no partial row mutation and durable timeout after release.

    #726 is now closed and Operations Done; all task containers/network/state/scratch are removed. Its receipt retains the observed maintenance repair lock-error counts and their separate scope. The reserved Rust Server owner retains selection/qualification of this fixed PHP reference and removal of the old update-validation maintenance-pause workaround. No shared/frozen fixture or reference manifest was edited, no native build ran, and no Rust session was resumed or replaced. This handoff does not clear the separate native config-audit/canonical-meter work for PR812 or the publication boundary.

  22. rmcdaniel commented on Oct 27, 2026

    @rmcdaniel
    MemberAuthor

    Rust owner checkpoint, 2026-10-27 17:45Z (new Claude session on the replacement Rust host).

    Next: land #814 and #815, then move to the RC items (publication under #450, then differential and performance qualification of the published native image).

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    authority:githubGitHub is the authoritative lifecycle record for this workcompletion:evidence-requiredClose only after all explicit acceptance and operational evidence is publicenhancementNew feature or requestintake:approvedCurrent issue title and body revision is approved for authority intakekind:cross-repositoryWork spans more than one public repositorykind:featureA public product capability or experience is requestedpriority:P1High-priority product or release riskrepo:serverOwned by the standalone server repositorystatus:readyReady for implementation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions