Repository navigation
Description
Current owner and release gates — 2026-11-09 23:54 UTC
General owns this P0 while SDK-PHP and Server are Off. The opt-in consumer is merged in #373, default enableActivityContinuation: false. It is source only and is not in published SDK 3.11.0.
Producer repair Server #1118, final head e0a22d863007c03812d736641666c0bb5e783dc3, passed all 62 final-head CI checks with one intended optional skip. Eleven HTTP controls pass on SQLite/MySQL/PostgreSQL and four continuation library controls pass, including deterministic signal/read atomicity. It remains in the protected merge queue. The initial two-transaction implementation does not clear publication.
SDK 3.12 release metadata and constructor usage are prepared on release/general-sdk-3.12.0, head 3734d585a97991c88d5d076dc5d5ef0834843e95. PHP 8.5.12 / Composer 2.10.3 validation and installed path-package registration identity pass; an intentionally wrong version is refused. This is source metadata qualification, not a published-package pass. Existing Server compatibility baselines remain unchanged.
Next: follow producer merge, then qualify Native 3.4 release source and the SDK release source before tagging. The installed pair must cover default-off, missing/older capability, accepted and declined continuation, unknown-outcome/exact-retry recovery and business-clock fallback using the actual worker and published producer. Record final result/history identity and exactly one activity callback under reply loss. Measure interleaved A/B only after installed correctness, on one fixed runtime/configuration. No speedup or completed-feature claim is made. The original acceptance remains open.
Original requirement and evidence
External report topic 24-sdk, accepted for P0 intake at the user's direction. The proposal, timings and supplied test results are unverified reference evidence. No patch was applied or executed during intake.
Implementation owner: general. The owning agent drives source, release and applicable published-artifact verification. Existing release, operating and credential gates remain in force.
Problem and proposed scope
With an explicitly supported producer, a worker can replay its admitted history with the completed activity result and propose the next workflow commands on that same completion request. Implement only the PHP SDK half; Server owns the producer and its versioned contract.
Acceptance
- Depend on the accepted and advertised Server contract in Native: atomically accept an opt-in workflow continuation with an activity result server#1078, including exact result/history identity, command eligibility, declines/errors, capacity and history-tail budgets. Do not infer capability from a draft field or manufacture Server behavior in the SDK.
- Add an explicit worker option that defaults OFF. A request-level optional field alone does not establish safe worker opt-in. Missing/older capability keeps the legacy completion/poll path.
- Preserve original activity and workflow identity, fencing, deadlines and completion-transit accounting. Never dispatch work merely because a received grant looks newly captured.
- Exclude local activities, parallel groups, selections, cancellation scopes, update/cancellation state, message cursors/waits and failed replay until separately supported. Replay must not repeat activity side effects or lose a successfully computed activity result.
- Validate a bounded correlated history tail and supported command allowlist. A decline or replay failure follows the truthful ordinary path; unknown transport/commit outcomes and backend errors must not be silently treated as ordinary declines.
- Preserve tick(), shutdown, telemetry, synchronous cases and old-Server fallback. Add real worker base/candidate controls and a supported published producer/SDK qualification before closing.
The supplied reference changes Client.php, Worker.php and WorkerContinuationTest.php against the reporter's older SDK base. Review its actual option/default behavior; the report's opt-in recommendation is not proof that the draft implements one. Existing P0 SDK#326–332 contracts and release gates remain separate.
Reported workload and evidence limits
The report describes 200 workflows, six PHP worker processes, five sequential 20 ms activities or five local activities, last-close wall time, and three or four interleaved A/B rounds. MySQL session-to-session drift is reported as high as 11%. Stock database durability, network placement and the absence of deferred projections are reporter conditions, not independently verified facts. The headline run covers topics 1–24; topic 25 has only a MySQL five-steps A/B. No speedup, production readiness or suite pass is accepted from this intake.
Sanitized reference data
The supplied Server series targets reported base d4c6de8d; the SDK reference targets 96dc061. Maintained heads were independently read as Server c3bbfa5f and SDK c87eae3. These cumulative references are not current-main patches or maintained qualification.
0001-Continue-a-run-s-workflow-task-from-its-activity-s-c.patch— 39,147 bytes / SHA-25637d05531ec36a7a9f90356018faae6bd6ce8e4f47d6e831caec38a7348308327.
Bench-only Server0001 is retained as diagnostic context, not a separate production change. Complete sanitized diff references, shared bundle identity and source-review findings are linked in the intake index and the issue comments. Original mail headers, author/date metadata, application commands and runner instructions are omitted.
Activity
rmcdaniel commentedon Nov 6, 2026
Sanitized external reference for topic 24-sdk:
0001-Continue-a-run-s-workflow-task-from-its-activity-s-c.patch, part 1/1. Complete sanitized diff: 39,147 bytes / SHA-25637d05531ec36a7a9f90356018faae6bd6ce8e4f47d6e831caec38a7348308327. Ordered parts preserve the complete diff bytes; none was applied or executed. The patch is a cumulative older-source draft, not maintained implementation or qualification. Mail headers/author/date/message/application instructions were removed.rmcdaniel commentedon Nov 6, 2026
sdk-php owns this P0 through source, release and applicable published producer/SDK verification. I read maintained SDK main
c87eae373325d0a5bc8529058984becf17c82793, the Server1078 acceptance, and the sanitized SDK reference as data only. Its 39,147 bytes / SHA-25637d05531ec36a7a9f90356018faae6bd6ce8e4f47d6e831caec38a7348308327match the filed reference. No patch was applied or executed, and no consumer implementation or runtime result is claimed.The finite current-source review identifies these required implementation boundaries:
record_side_effectcallback before returning commands (Replayer.php/WorkflowCommand.php); the reference filters the returned command list afterward. It blocks local callbacks but that is not a general speculative execution boundary. An eligibility/command-admission mode must refuse unsupported callback work before it runs, preserve the already-computed remote activity result and leave ordinary replay available. Allowed returned commands alone also do not prove the admitted prefix lacks the excluded group/selection/local/cancellation/update/message state. ReplayResult exposes several prepared-local/scope/cancellation intents, but the complete producer-defined eligibility trace/prefix checks remain required.retryStorageAdmissionintentionally returns null after an uncertain activity completion is proven committed by exact task/attempt/owner/status evidence. The reference routes its completion intocontinued(..., array $completion). A port must explicitly handle the maintained null/commit-proof case rather than letting it become an application activity failure or rerun. The proof establishes the activity result, not whether proposed workflow commands committed. Server1078 must define continuation receipt/recovery for that lost-response case; it cannot be relabeled an ordinary eligibility decline.Next action / owners: I requested Server's versioned accepted+advertised #1078 request/reply/capability, canonical result/history/clock, command/eligibility, decline/error/recovery, capacity and history-tail budget checkpoint, coordinated with #1060/#1061/#1062/#1067. Server owns producer implementation and vectors; sdk-php owns its own default-off consumer and real worker base/candidate controls once that handoff exists. No published producer/SDK tuple is accepted yet. The immediate source task is this pre-execution eligibility/default-off/result-retention review, not applying the cumulative reference or inventing a producer shape. #340 Source/effect and #339/#337 maintenance-quality/release holds remain separate.
rmcdaniel commentedon Nov 6, 2026
Intake is filed as P0, owner sdk-php. Shared index, allocation and static review findings.
Complete sanitized diff reference(s): 0001 part 1/1.
Shared Lockbox bundle:
lab4/general/dw-performance-intake/2026-11-06/sanitized-tricks-20-25.zip(101,306 bytes; SHA-2563e5b593ed89536451be1c8d74abf2ee6e4782cd3f7a75fe5fc9a645d648a52da). Its roundtrip and member hashes are verified. The supplied patches and benchmark results remain external reference data; no patch was applied or executed during intake. Existing issue acceptance and subsequent owner review remain in force.rmcdaniel commentedon Nov 7, 2026
I reread Server1078 and the completed intake: no accepted advertised continuation wire/result/history/closed-decline/budget contract has been returned. The five concrete SDK findings at6697722902 and producer request6697723363 remain the source plan, including pre-execution eligibility, explicit default-OFF Worker option, canonical completion authority and unknown-commit handling. Actual3.9.5 delivers only separate helper/grant changes and enables no continuation. Next owner/action: Server supplies the versioned producer contract and truthful error disposition; sdk-php then owns the consumer and causal old-Server/default-off/fence/deadline/replay controls. No Server implementation or reference patch was executed.
rmcdaniel commentedon Nov 7, 2026
Handoff audit after the separate #328–#332 source cohort: Server #1078 still has no accepted, advertised continuation wire/result/history/closed-decline/budget handoff. Its broad error-softening finding remains material; the carried-poll and pipeline changes do not implement continuation. I re-read the primary producer record and retained the five SDK findings.
Next owner/action: Server returns that versioned contract and truthful unknown-commit/error authority; General retains producer ordering. sdk-php then implements pre-execution eligibility and an explicit default-OFF Worker option, with old-Server, lease/fence/deadline/transit and replay controls. The producer owner has been asked; no reference patch or Server implementation was run.
rmcdaniel commentedon Nov 7, 2026
Recheck 2026-11-07 19:40 UTC: server#1078 still has no accepted, advertised continuation contract (last activity 2026-11-06). Nothing in the 3.10 cohort implements continuation.
Next owner / action: Server returns the versioned wire/result/history/decline/budget contract and truthful unknown-commit error handling. sdk-php then adds the default-OFF Worker option, pre-execution eligibility, and old-Server/lease/replay controls. I asked Server in chat today for a date or the specific blocker.
rmcdaniel commentedon Nov 7, 2026
Server posted contract draft v0 on server#1078. My consumer-fit review is server#1078/6712366270: D1 (a), include version markers (D2), no eager dispatch (D3), and one blocking gap (F1: the SDK can't learn the events its own workflow-task completion recorded). Next: Server answers F1–F6, then General selects D1–D3. No SDK code until the contract is accepted and advertised.
rmcdaniel commentedon Nov 7, 2026
Server accepted all six consumer findings in v1 amendments:
On F4, faults and unknown commits share the same 503; re-sending the identical completion is safe for both, which works for the SDK. A distinct rollback code is listed as optional D4. Next: Security review, then General selects D1–D4. sdk-php starts implementation only once the contract is accepted and advertised.
rmcdaniel commentedon Nov 8, 2026
Operator nudge: this benchmax ticket (P0) has had no linked PR and no activity for about 8 h. It is the SDK side of server#1078 (opt-in workflow continuation with an activity completion): please coordinate with that server ticket and start a draft PR as soon as the shape is agreed. If it is blocked on the server side, add the status:blocked label with a one-line reason.
rmcdaniel commentedon Nov 9, 2026
Opt-in consumer merged in #373 (14:46 UTC): the Worker option
enableActivityContinuationdefaults off and is used only when the server advertisesactivity_workflow_continuationv1. The producer (durable-workflow/server#1116) is in the merge queue. Validated end to end against the producer branch (9/9 accepted, results correct, full-history replay clean). Still open: a Native release carrying the capability, an SDK release, installed producer/consumer qualification of the published pair, and a measured A/B before any speedup claim.rmcdaniel commentedon Nov 9, 2026
General is holding the next continuation SDK/Native publication while repairing the producer atomic-transition and exact retry-receipt gaps found in the release audit: durable-workflow/server#1078 . The merged opt-in consumer and its prior source checks remain source evidence only. Next: producer repair and three-backend HTTP controls, then the matching published pair and installed qualification; no default enablement or speedup claim.
rmcdaniel commentedon Nov 11, 2026
PHP SDK 3.12.0 is released (https://github.com/durable-workflow/sdk-php/releases/tag/3.12.0, on Packagist) with
enableActivityContinuationdefault-off. Its producer, Native Server 3.4.0, is published (server#1078); alias promotion is in progress. Remaining for this issue: installed acceptance of the published pair, then the measured A/B. Owner: General.rmcdaniel commentedon Nov 11, 2026
Installed acceptance, 2026-11-11 (General): correctness PASS, latency FAIL.
Published pair: Native Server 3.4.0 (
sha256:ba6aefb2…, published Compose with MySQL 8.0) + PHP SDK 3.12.0 from Packagist. Three sequential activities, 40 runs per mode, interleaved off/on/off/on.accepted(no declines/skips) withenableActivityContinuation: true.Release notes for Server 3.4.0 and SDK 3.12.0 now say not to enable continuations until #1129 ships. This issue stays open for the fixed-release re-run and the A/B.
rmcdaniel commentedon Nov 11, 2026
Diagnosis (server, 2026-11-11): not a missing Server wake. The native continuation commit (
rust/src/runtime/continuation.rs) callswake.notify_waiters()after commit, as ordinary completion does. The 5 s comes from sdk-php 3.12.0's poll order: after an accepted continuation the next activity is already ready, butWorker::performTickstarts the next tick with a workflow long poll atrun()'s default 5 s timeout. The Server'scross_kind_poll_wakeonly reports work that becomes ready during a held poll, so that poll waits the full timeout, then the activity poll takes the task at once. The ordinary path is unaffected because the activity result creates a workflow task the workflow poll takes immediately.Fix: #375. An accepted continuation requests a poll sweep, so the next tick does not wait. It includes a regression test that fails on 3.12.0 behavior. No Server change. Next: General merges, releases sdk-php 3.12.1 and re-runs the installed comparison.
rmcdaniel commentedon Nov 11, 2026
Done (General, 2026-11-11). Opt-in activity continuations ship in PHP SDK 3.12.0 with the 3.12.1 latency fix, producer Native Server 3.4.0.
Installed acceptance of the published pair (Server 3.4.0 index
sha256:ba6aefb2…via published Compose with MySQL 8.0, SDK 3.12.1 from Packagist), 3 sequential activities, 40 runs per mode, interleaved:accepted, none declined or skipped.