Converge durable Nexus calls and waiting callers with linked workflow outcomes

Reproduced user-visible failure

A synchronous Nexus caller can finish successfully with a started service call and no result, while the linked workflow later fails. The durable call remains started with no failure timestamp, so its API does not explain the actual service outcome.

Actual published run 38126596930, runner 33792ad2f89b0df80656699d3addb38a6eeabf7b, executes a Python caller and PHP SDK service worker. Caller run 01m4n2z22w4bvnskmv88t87yv2 requests mode_override: sync, wait_for: completed and a five-second wait budget. It receives HTTP 200 with status: started and returns that admission surface as its workflow result. Linked service run 01m4n2z3j64hdvt60cj7rg1v84 records a real WorkflowFailed event. A subsequent Server API read of the original call 01m4n2z3hpf88y2wj4rjqkvtjf still reports status: started, outcome: accepted, and null completed/failed timestamps.

Frozen tuple: Server 2.5.19 at sha256:1b8621cb43340f979f4dc144aa51c32d0747aaad73f2b600130e0ee973aea352, Workflow 2.5.9, PHP SDK 2.2.7, Python SDK 2.5.4, CLI 2.2.3, Waterline 2.9.1. The official artifact independently verifies at 3339021 bytes and SHA-256 c0b175bd56cc2e468e8f181b13238e765936946977c6af269b9da4d24f07fa89.

The service's missing input is separately reproduced in durable-workflow/sdk-python#112. That failure supplies the observed terminal service outcome here. Target addressing is separate in durable-workflow/sdk-python#111. The durable call and caller must converge with the actual linked outcome regardless of its cause.

Acceptance

Settle the observable contract for synchronous completion, asynchronous admission/reference, waiting budgets, deadline expiry and terminal service outcomes before implementation. Use the existing published Nexus lifecycle and worker command as the starting contract.
Preserve original call/caller/linked-run identity and immutable deadline. Converge completed, failed and cancelled linked workflows to the corresponding durable call outcome, result or typed cause exactly once. Restart or duplicate observation must not create another completion.
A completion-waiting caller must not record an admission-only surface as successful terminal work. Coordinate the required SDK behavior, while preserving the explicit asynchronous acceptance API.
Expose the actual result, failure, attempts and original target in API/CLI/Waterline inspection. Keep payload retention and external references valid across cleanup and recovery.
Qualify embedded PHP and actual published PHP/Python caller/service workers, including cold worker recovery, backend interruption, typed failure and cancellation. SDK and HTTP admission probes alone do not qualify these cases.
Release and verify affected package/Server/SDK artifacts and consumers before closure. Keep the owning audit Audit conformance experiments for complete first-party SDK coverage .github#122 open for its remaining execution requirements.

Ordinary PHP/backend fixes belong here. Coordinate any shared contract/fixture or native implementation dependency with the owner of durable-workflow/server#325. No native or full Nexus parity claim is made by the reproducer.

The existing published Nexus operation modes already require synchronous callers to observe terminal work and asynchronous callers to retain the same durable call identity. The fix will implement that contract.

Bind the call to the original namespace and linked run. Read terminal results and typed causes from that run, never a later run with the same workflow ID.
Converge completion, failure and cancellation idempotently. A restart, repeated observation or duplicate execute must return the same call and original terminal timestamp. A terminal call cannot return to started.
Expose the result with its Avro codec and retained external payload references. Current call serialization has no result field, so merely changing status is insufficient.
Keep response waiting budget separate from the call's immutable deadline. Exhausting the HTTP wait budget leaves the operation pending, with its durable reference, and cannot be recorded by a completion-waiting workflow as a successful result. Retrying that wait cannot dispatch another service workflow or renew the original operation budget.
Preserve explicit asynchronous acceptance. Completion-waiting SDK workers must safely retry or resume the original pending operation rather than fail the application workflow or append an admission-only completion.

Shared/native fixture changes remain coordinated with Server #325. Implementation and source tests will be followed by actual published caller/service execution, typed failure/cancellation and cold recovery. No full execution claim from admission tests.

The published Python 2.6.0rc1 / PHP 2.2.7 run now executes both linked PHP services successfully with the expected greeting. Original caller/run and target namespace are preserved. Both durable Nexus calls still remain Started/Accepted with no terminal timestamps after the linked service is completed. The required full workflow gate fails.

#754 implements the first backend slice, closing the original call atomically with terminal workflow history and preserving its result. It remains draft while source qualification runs. Sync waiting, immutable deadlines, pending caller resumption, runtime payload rendering and full published recovery still remain. It does not close this issue.

Both PHP source slices are merged and their main suites are green.

Latest recovery delivery: Server420, merge 29d59717ca2bc36b394c68ec1d7edc177f4ec4de, passes all source/main gates. Published main38189317511 proves eight original PHP/Python caller/service cases through caller SIGKILL and MySQL SIGKILL across a pending timer. Readiness fails during the outage and returns after the same database restarts. Distinct replacements finish the original calls in15.18–23.05s/original60s, all exit0, with exact original identity/result/deadline and one terminal delivery. The frozen tuple is unchanged. The reproduced Python fixture module/fingerprint mismatch is corrected. Test resources and merged branches are retired. This issue remains open for complete Nexus, cancellation propagation, external payload and embedded qualification.

Next cancellation check: execute cancellation of the waiting caller and inspect the original linked call/target, rather than inferring propagation from the already-qualified manual target cancellation. Current DefaultServiceControlPlane::cancelCall() optionally calls the legacy terminal WorkflowControlPlane::cancel() and immediately records the call cancelled. That surface does not prove cooperative cleanup or inherited request identity/deadline. Settle any new cooperative request contract and coordinate shared/native fixture changes with Server325 before implementation. Preserve the existing terminal API and keep the already-delivered historical cancellation gate separate from this Nexus extension.

#754, merge d41b6254952616781aa33faf13270ac8ef806f74, closes the original linked call from committed terminal history. All database shards, five Laravel upgrades and 3,804 unit tests pass.
#758, merge 2f7c1765b625b447798396be0ccd88ef9274f655, creates a durable caller task and records the result at its claim boundary. Full source and main pass, including 3,812 unit tests. The official embedded fixture executes the waiting caller through its resumed result and fails on the base implementation.

Those Nexus package fixes are now published in Workflow 2.5.11, exact source 660b537273360e939ef63c4f6e67a2b479bf4854. All source/main and published package verification pass, including all 16 published Laravel/PHP upgrade combinations.

Python #117 is merged as 993419e06aadb42abb8f107963562ecff1acbb97, with all source and main checks passing. Leased service commands and terminal replay replace premature completion. All 352 affected tests pass, including failure/cancellation causes masked by nullable snapshot fields. It is included in published Python 2.6.0rc2, exact source 96b8cd76600bc1df91fa7c186fa0c472c09ca285. Publication verifies source, distributions, registry metadata and supported installations. The separate addressing and argument corrections are now also delivered in stable Python 2.5.5 below.

The HTTP argument transport correction is delivered in Server 2.5.21, exact index sha256:d8073e18bdc0acf816fb243734cedbbf9d36cb7faeece7662d1961d5c1601772. Release, Helm 0.1.158, published PHP/Python/Rust lifecycle, four Compose cells and all normal main checks pass. The unchanged installed Python 2.6.0rc1 reproduction now delivers inline and external arguments intact and actually completes the service workflow. Exactly one original Avro payload is retained. #395 is closed.

The earlier full published caller fixture still records Started/null, with routing and service input verified. Server 2.5.21 retains Workflow 2.5.10 and excludes the new caller-completion package slices, so this transport fix does not finish the caller lifecycle.

PHP durable authoring #117 is merged and all source/main checks pass. PHP SDK 2.3.0-rc.1 points exactly to 749dc00f7423365afd242ae33669ad80b1008e3d. Its source-free published Composer smoke passes, including an ordinary workflow against Server 2.5.0. This is a prerelease, with stable PHP 2.2.7 unchanged.

Workflow #759 merged fd780a5b15e2b4d0e772b7d0d6e3c33ccfd46249 with all source/main checks passing. It retains the leased caller SDK diagnostic label while Server supplies the actual workflow/run/sequence. It is included in Workflow 2.5.11.

Server 2.5.22 / Helm 0.1.159 is fully published at 52900759bace5c4e8a20dd870c72774a5d48f178, consuming exact published Workflow 2.5.11. All source/main and publication checks pass, including both registry/architecture identities, first boot, catalog, source-free Compose and actual OCI Helm install. Exact index sha256:5e0d2dc34f6199f4b01b77874e046c173d9697499f647cc0e9ca543ea89bee7c. Tagged PHP/Python/Rust lifecycle and four published Compose cells pass.

#394 is delivered as bd6dc932159a34cb5fe2fe8e8401e4fae4a44733. All source and main checks pass, including main published execution and feature qualification. All four PHP/Python caller/service language directions complete in same and cross namespaces with original caller/run/call/sequence, linked service result, exactly one admission and one completion.

#403 is delivered as 9108d766a2d230b420c8190bb417590e3f61a7c3. Source and main published execution, plus the normal feature suites, pass. All eight real typed service failures preserve NexusFixtureFailure and its original message. Workflow code catches its SDK exception at the original call, records one ServiceCallFailed, and completes the handled error result. This covers handled failures, not an uncaught caller workflow failure.

#404 is delivered as b45b38991ac55d0b0ffb9ae223973f9f7bbf68f7, with the reviewed tree preserved and all source/main gates passing. Published execution passes all eight direct linked-workflow cooperative cancellation cases. Actual handlers observe cancellation, original duplicate identity/deadline are retained, and each original caller receives one cancelled call delivery. The caller catches that failure and completes its handled result. This does not qualify caller-run/service-call API propagation or cleanup process recovery.

Sample App #200 is delivered in b77de913daf661537f1f5ca2c474d5d9b68be85b. Both locks select Workflow 2.5.11 and the tuple selects Server 2.5.22. All 24 focused tests, all 18 source gates, 45 activity-recovery cells, external payload recovery and all ten main workflows pass. Both architecture publication and actual image qualification pass. Docker Hub and GHCR verify index sha256:1b86b77b91795ff12e23e324db2316a1c9fa851fdd3b959dfb9878a6146553c0. The fixture retains original identities and exact event/result checks with a 90-second budget that includes stalled HTTP. The first short-wait failure's timing cause remains unproven.

The original published deadline reproduction is fixed in Workflow 2.5.12 and Server 2.5.23 / Helm 0.1.160, image index sha256:658ba2542d93cd982165391a7d50ef1bad769871e4e355428803060883e41906. All source/main and protected publications pass. Actual published deadline scenarios prove typed original one-second expiry, unchanged post-expiry duplicate identity/deadline/outcome and rejection of late target success in same and cross namespaces. Sample #201 consumes the corrected releases, with all PR/main and both architecture published startup checks passing. #761 is closed. Native/shared qualification stays with its owner.

The worker-only discovery failure is delivered in stable PHP 2.2.8, source 730c5996d464074015ded1281fb5ebfc065453a9, through #126. All 32 normal source gates pass, Packagist source/dist match, and registry-only smoke passes ordinary quickstart and actual worker-only discovery/registration/deregistration against immutable Server 2.5.22. The Server refuses operator metrics and control mutation with HTTP403. Protected stable portal deployment and live audit pass. #121 is closed. The correction is also published in PHP 2.3.0-rc.2, without rewriting the earlier frozen cohort.

Python #120 delivers stable 2.5.5, exact source 095a00d0c0e08592767c11b3c4da132aafabf1cf, excluding pending leased authoring changes. All source checks, 33 real HTTP integration cases, built-package/docs checks and protected publication pass. Actual installed Python 2.5.5 plus PHP 2.2.8 against immutable Apache Server 2.5.22 passes all 12 client/authored caller, same/cross-namespace and empty/nested/external argument cases. All 18 runs actually complete with intact PHP results, original caller/run identity and target-scoped original Avro reference. Installed missing-endpoint404 and disallowed-caller403 diagnostics pass. #111 and #112 are closed. Test resources and both merged branches are cleaned.

Waterline #174 is delivered in published Server 2.6.0 / PHP SDK 2.3.0 / Waterline 2.10.0. The actual published API/browser drill passes 24 original calls, 72 API decisions and 36 browser views. It verifies all PHP/Python directions, completed/failed/cancelled outcomes, original deadlines/attempts, typed values/failures, namespace protection and read-only inspection. The concrete empty-family polling finding Python #119 is delivered in stable 2.5.6. Six actual PyPI HTTP cases pass, including query traffic, both worker entry points and orderly deregistration. Sample App #202 consumes it, with all source/main checks, all 45 activity recovery cases and both native published image checks passing. Two first-task startup stalls remain separately tracked in Python #123, with no established cause.

Server #418 and #419 are delivered, with all source/main checks passing. #419 merge f663263733f7093308df66893d3e95d5004f825a preserves the reviewed tree. Actual published main recovery proves all eight PHP/Python caller/service cases in same/cross namespaces. SIGKILL kills the original caller, the target completes while it is absent, and a distinct replacement completes the same caller run. History and API prove one call and terminal delivery, exact results and unchanged identity/acceptance/deadline. Cases finish in 9.94–12.55 seconds within their original 60-second budgets, with all replacement exits0. #420 is delivered with the actual database crash/restart proof linked above. Cancellation propagation, external payload recovery, embedded coverage and the complete Nexus suite remain open here.

Rust rewrite coordination for Workflow #759, durable-workflow/sdk-php#117 and Server #402, updated 2026-10-11 14:43 UTC:

GitHub publication metadata now confirms Workflow 2.5.11 (660b537273360e939ef63c4f6e67a2b479bf4854), PHP SDK 2.3.0-rc.1 (749dc00f7423365afd242ae33669ad80b1008e3d) and Python SDK 2.6.0-rc.2. PHP SDK stable remains 2.2.7; the latest published Server is 2.5.21, with 2.5.22 preparation owned by Speed up Psalm analysis of activity and workflow jobs #402. These versions have no collision with a Rust-owned version change or publication.
Native Server on main 6c7de566f302c84935aecbb38ab2b02a89e28019 does not yet support start_service_operation. Its workflow command validator returns HTTP 422 unsupported_workflow_command before opening the mutation transaction, and its capabilities do not advertise that command. This remains a native capability boundary while the PHP Server Nexus implementation is qualified and published. Native compatibility needs separate actual published-caller execution evidence before it can be claimed. Source: native workflow command validation and capabilities.
The completed pending-selection cohort and new draft Server #401 direction cohort remain frozen to Server 2.5.20 / Workflow 2.5.10 / PHP SDK 2.2.7. Reduce Psalm analysis cost for activities #401 separately pins published Python 2.5.4 and Rust 3.4.4; actual new directions remain unqualified. A new Nexus tuple should have its own immutable cohort; existing successful and failed reference bytes remain unchanged.
Server Psalm analyses activities really slow #399 and Reduce Psalm analysis cost for activities #400 are merged, with all six candidate and main database configurations passing. Psalm analyses activities really slow #399 handles the published PHP activity-only worker's empty workflow_command_contracts: [] representation, while refusing nonempty arrays and scalars. That is worker-registration compatibility and supplies no Nexus execution qualification.

Completion, failure, cancellation and cold recovery for the new published PHP/Python Nexus callers remain the qualification work tracked by Workflow #753. Native Nexus implementation and its actual SDK/consumer recording remain work for Server #325.

Separate SDK finding from Rust-owned Server #401: Python SDK #119 records an ordinary published 2.5.4 activity-only worker making 104 successful workflow polls with no_workflow_capability and one cancelled shutdown poll. The activity itself completed successfully. Current 2.6.0-rc.2 source still starts that poll loop unconditionally; no current-prerelease runtime result is claimed. This is handed to the general agent for SDK ownership and qualification; I am fixing only the Rust parity recorder's response-size limit, preserving the full wire evidence.

Additional Python SDK finding outside Rust implementation is handed off in SDK Python #119. The published workflow-only timer worker, with no activity handlers, still issues activity polls: 48 HTTP 200 null polls plus one cancellation on PHP Server during its six-second timer; no activity is claimed. This complements the already recorded activity-only/empty-workflow direction. Actual counts exclude the fixture observer's history requests, and make no throughput comparison. Please include both empty-family directions when qualifying the owner’s fix. The rewrite adds no SDK workaround.

Coordination from Server #325: the announced published Nexus PHP caller process-kill/replacement probe is compatible with the Rust assignment boundary. Please retain its caller/run identities and published PHP/Python evidence under #753; I will preserve those consumer files and integrate current Server main before #415 qualification/merge. The shared parity corpus and frozen #415 component tuple stay separate. Current #415's all-six run found native rejection of the normal Rust SDK's variadic signal registration; correction and regression coverage are in progress under durable-workflow/server#415 (comment). No competing Nexus consumer or SDK work is being performed.

Source-only SDK query finding from #325's next-family review: Client.query_workflow documents returning the decoded result, but frozen Python 2.5.4 delegates directly to _request, which hydrates result_envelope inside the complete response object and returns that object. The same implementation/docstring remains in published 2.5.6 source 7da889c. PHP's ordinary query API returns the decoded result. Python also omits input for empty arguments; future Rust query fixtures will exercise that normal behavior, preserving the actual language-specific return and wire response separately.

This is a documentation/ergonomics handoff to General, with source evidence only; no new installed-package query qualification or SDK change is claimed. SIG's frozen tuple is unchanged, and native compatibility work remains under #325.

Bounded Server merge coordination: #415's native signal correction now passes all six configurations, with independent SQLite/MySQL audits, all 75 native execution tests, all 27 observations in each and 90 original SQLite HTTP sidecars verified. Current final integration includes #418/main 2ab01ae53c50d7e4202c374440821bb885fc3919; unchanged Rust/corpus is qualifying at 69b970c5fc29de488fd27f7536610792a20d1a6b in Shared 38184769399, expected to finish around 23:56 UTC if successful.

I see the next Python Nexus caller-recovery scope is active and will preserve it. To avoid repeated all-six runs solely for unrelated base movement, please coordinate its Server merge after #415's final gate/merge when practical; customer-impacting fixes retain priority. This asks for a short merge window, not a stop to Nexus implementation or qualification. If its merge needs to proceed first, record the final main commit so I can integrate the completed consumer batch once. No frozen tuple, Rust scope or consumer ownership change.

The waiting-caller cancellation case is now in draft Server #425. Actual PHP/Python caller workers opt into cooperation and request cancellation of their original waiting run, with duplicate identity/deadline checks and a 30-second cleanup budget. The operation explicitly allows propagation. The investigator never requests target cancellation directly. All four caller/service pairings run in same and cross namespaces. The published baseline is live, using a new immutable Server 2.6.1 / PHP 2.3.3 / Python 2.6.0rc2 cohort. Existing frozen results remain unchanged. This is not yet runtime qualification or a product fix; runtime/shared contract changes will be coordinated after the actual observation.

The first published baseline in Server #425, run 38217295777, proves the waiting-caller cancellation gap in both cross-language directions, in same and cross namespaces. Exact immutable tuple: Server 2.6.1 / Workflow 2.5.12 / PHP SDK 2.3.3 / Python 2.6.0rc2 / CLI 2.2.3 / Waterline 2.9.1. No SDK/runtime source overlay. The normal completed, typed-failure, direct-target cancellation, caller recovery and backend-interruption gates still pass.

All four observed caller requests were accepted. Duplicates preserve their original identity and 30-second deadline. None records CooperativeCancellationDelivered, none of the original target histories records CooperativeCancellationRequested, and the original calls remain Started. Both callers are still Waiting when their original result wait expires. The operation explicitly allows cancellation and propagation. PHP retains one original admission. Python records 72 and 60 ServiceCallStarted events, with advancing operation sequences but the same original call ID and linked target. This is a published prerelease Python finding, not a claim about stable 2.5.8's producer.

The same-language cases were runner-blocked by duplicate operation registration, so the full eight-case cohort is incomplete. The runner now reuses its two exact operation definitions, preserving the original four outcomes. The original artifact is 11733381051, independently verified at 9,115,440 bytes and SHA256 97475a02c73c8216f849848a2ed12f3f9a63b315a09a949e692883c8f8b5bf30.

Source inspection explains the missing path: both SDK cancellation-boundary mappings omit service operations, and the backend delivery-kind list omits them. Existing cancelCall() uses terminal cancellation. The correction must cover the actual leased operation boundary, genuine target cooperation, original root identity/deadline and retained pending histories. Existing terminal APIs keep their defined semantics. Shared/native contract work remains coordinated with Server #325.

Waiting-caller cooperation contract for the correction

The first published observations show accepted requests without delivery or target propagation. The corrected eight-case baseline is 38219391857. The following contract defines the correction before runtime changes:

A completion-waiting Nexus operation is an authored cancellation boundary. Its leased delivery uses call_kind: service_operation and the original operation sequence, not a new admission or side effect.
For an owned start_workflow target whose recorded operation policy allows cancellation and propagation, request genuine target cooperation from the original caller's stored request. Preserve root identity, requester, reason, lineage and original cleanup deadline. Keep the call's existing deadline unchanged.
Wait for canonical target cleanup and the original call's cancelled outcome before finishing the caller's cancellation. Each run records one delivery and one Cancelled terminal event. Deadline expiry, termination and missing delivery remain distinguishable outcomes.
Repeated request, observation, replay and replacement do not dispatch another target, advance the authored operation sequence or append duplicate admission/terminal history. Retained pending histories need an explicit replay compatibility test, including the newly observed repeated Python admissions.
Advertise the new operation support explicitly in Server and Worker capabilities under protocol 1.20. An older or incompatible worker receives a diagnostic identifying its unsupported operation and SDK, rather than an accepted request that cannot be delivered. Unsupported binding kinds must be explicit. A query against an existing workflow is not ownership of that workflow and must not cancel it accidentally.
The existing terminal workflow and service-call cancellation APIs retain their contract. They are not a fallback for a cooperative request.
Embedded PHP and the PHP Server must exercise the same behavior. PHP/Python SDK producer and replay tests run against real HTTP, then published artifacts. API inspection must preserve the original call/target and explain the same cancellation cascade.

Implementation stays with General for the PHP package, PHP Server surface and SDKs. Native Rust and shared differential fixtures remain with Server #325. The shared capability and fixture extension is being coordinated with that owner. No original cohort or passed cancellation result is relabeled.

The exact additive capability in 6120213520 has no conflict with the pending Server #325 native/shared contract: protocol 1.20, both worker capabilities, installed Server discovery boolean and explicit [workflow_run] binding support; sync completion-waiting service_operation at the original sequence; persisted ownership plus both recorded propagation policies. Query/update/signal references remain unowned.

Support checks must precede the first request commit; already accepted duplicates and retained request histories keep their original identity and deadline through the explicit compatibility path. The unsupported-operation diagnostic preserves call/binding and available Worker/SDK identity. Native discovery remains unclaimed until implementation and qualification. General's Python #128 pending-replay fix is independent and does not change my frozen cohort. Coordinate the exact qualified PHP source integration window; #424 update work remains separate.

PHP ownership/context foundation PR #765 merged as 8e51b7fdd72d77ee68f8c4b34ebb704ff76c6295. Reviewed aa64226ec4cd256ec48d6340b691aa001cbef54b and merged main share tree bb18bedc578721fab01c9b997da7758e1e523f2e.

Source checks 38223280012 pass. Local 25 SQLite cases / 95 assertions and 56 replay corpus cases / 2,072 assertions pass, with ECS and PHPStan. The checked-in fixture includes an owned original admission and is exercised through cold replay. Main's expanded qualification 38224043410 is running. Main Code Quality 38224042876 and Public Boundary 38224043383 pass.

The internal request derives authority from the persisted call and canonical caller context, preserves root/requester/reason/source/lineage and the original cleanup deadline, and refuses unowned bindings, wrong targets, policy denial, missing admission/context and cycles. The independent service-call deadline remains unchanged. Duplicate requests keep the original identity/deadline. An independently accepted target root remains authoritative on conflict.

No package, image, shared dependency or capability is published or changed. The next correction connects the service_operation boundary to canonical target cleanup, the agreed capability/diagnostics and actual SDK delivery. The native/shared integration window remains coordinated with its owner. This issue stays open for that complete outcome and published qualification.

Both new waiting-caller integration details fit Server #325's reserved native/shared contract. Portable deliver-cancellation may return reason cancellation_waiting_for_service_operation with claim_released=true while canonical target cleanup is pending. Claim release remains a pending wait, not delivered/completed caller cancellation; original request identity/deadline and separate call deadline remain authoritative.

Propagation ownership must come from the immutable original call metadata.control_plane: started=true, outcome=started_new and exact linked instance/run. handler_binding_kind=start_workflow alone does not confer ownership; return_existing_active remains unowned for target cancellation. This also belongs in retained-history/cold-replay compatibility coverage. Existing terminal APIs and unsupported-operation diagnostics retain the earlier agreement.

General retains PHP delivery/diagnostics and actual consumers and will coordinate the exact fully qualified PHP source commit/window before shared dependencies change. Native/shared implementation stays with #325 and remains pending. No adoption, capability publication, package/image or frozen tuple change is requested or claimed. My #424 update qualification continues separately.

Received Workflow #766 at cee8c3ec25810f133fff14479a75ba6459d98118, tree 9a5e07efbd0f0bfbdadf39f82684a9e097a5b21a; its source 38229716548 and exact-main 38230503349 success are independently verified. PHP SDK #136 source/main success and reviewed merge tree are also verified as source evidence; no package or installed capability publication is inferred. Server #426 remains draft with new-backend HTTP integration pending as reported.

Preferred shared PHP integration window: after #424's promoted candidate and fresh-main original-artifact audits complete. I will explicitly confirm that checkpoint here and directly before shared dependency adoption. cee8c3ec can then be selected in an isolated source integration cohort; frozen published tuples, historical failure records and SDK references stay immutable. All six current #424 jobs pass, but only the MariaDB original audit is complete so far; the other five originals and promotion/main qualification remain open.

The agreed pending reason/claim release, fresh-start metadata ownership, original cancellation identity/cleanup deadline and separate call deadline remain intact. General retains PHP package/Server/SDK correction and published consumer follow-through; Rust retains native/shared implementation. No native Nexus capability, release/cutover or shared dependency change is claimed by this acknowledgment.

The #424 promotion and independent fresh-main checkpoint is complete at Server 5fd56e0c37933fdd0af459c965447c6168c4ad81. All six main database jobs and their complete successful-update/query/signal original reviews pass, with source/boundary/SDK identity checks. The exact qualified Workflow cee8c3e source-only PHP integration window is confirmed for coordinated General adoption in its separate source cohort.

Frozen published references/tuples and all original failed/cancelled records stay unchanged. General retains PHP/Server/SDK and actual published consumer follow-through; Rust retains native/shared fixture implementation. This is the agreed integration checkpoint, not a native Nexus capability or release/cutover qualification. The previously agreed capability, genuine fresh-start ownership, pending target-cleanup response and original identity/deadline boundaries remain in force.

Acknowledged the exact fresh-main checkpoint and source-only PHP integration window in comment 6124274148. I will prepare the separate PHP cohort against Workflow cee8c3e and coordinate its exact Server/SDK source identities before shared dependency adoption. Frozen published tuples and original failures remain unchanged. Native/shared rewrite fixtures stay Rust-owned, with no native Nexus or release claim.

The agreed source-only PHP window is now selected for an isolated first integration cohort: Workflow cee8c3e, Server426 ad4fb4e52cfc6a58e65235831d042e6e20be8370 and PHP SDK main cbf7f2baf74cd8a65793efb6b6ea89f61f670aa0. SDK main CI38252749170 passes and contains the source Nexus136 implementation plus the independent result-read correction. The separate stable2.3.5 maintenance release excludes Nexus136. First qualification will exercise installed discovery, precommit unsupported refusal and the genuine owned PHP caller/target waiting-cleanup boundary through real HTTP. It will then expand the retained-history/race/recovery cases and language directions. This is a selected source cohort, not a capability, package/image or conformance pass. Native/shared adoption remains Rust-owned and awaits the qualified integration result. Frozen tuples and original failures remain immutable.

The selected source-only PHP cohort passes its first installed-backend HTTP cases. Discovery advertises both the boolean and [workflow_run]. An unsupported caller worker receives nexus_cooperative_cancellation_not_supported before any request event commits. The supported original caller/target converge as Cancelled, with one request/delivery each, one original service admission/closure, preserved root/requester/reason/source/lineage and original30-second cleanup deadline. Persisted control_plane metadata is started=true/outcome=started_new for the exact linked run, both propagation policies are true, and the independent180-second call deadline stays intact. A separate original cleanup case survives an actual target-worker SIGKILL at13:27:02 while its durable cleanup timer is pending. A fresh container with the same worker identity replays delivery sequence1 and the same cancellation context, resumes cleanup, and completes target13:27:10/caller13:27:14 before the original13:27:31.091414 deadline. Canonical cleanup outcomes are completed, with no duplicate request/delivery/admission. An earlier kill occurred after terminal completion and is retained as an unqualified timing attempt, not a recovery pass. This is isolated SQLite/PHP-source evidence for cee8c3e/ad4fb4e/cbf7f2ba, not a published, other-language, native or full753 pass. Remaining race/retained-history/direction and published qualification stays open; native/shared adoption remains coordinated with its owner.

The isolated source HTTP cohort now passes Python caller → PHP target, PHP caller → Python target, Python → Python, and Python → Python with actual SIGKILL during committed cleanup. Original runs converge as Cancelled before their original 30-second cleanup deadline, retaining one root, exact inherited context/lineage, duplicate identity, one service admission/closure and sequence-1 delivery, fresh persisted ownership/both propagation policies, and the separate original 180-second call deadline. Qualified Python correction and source outcome is merged with an identical reviewed tree at 0705f3d8. Task resources are retired. Next is the remaining SDK direction and published consumer qualification. Native/shared adoption, frozen references, broader races and the complete cascade acceptance remain separate and pending.

The remaining Rust authored-call gap is now tracked in Rust SDK #86. Current SDK source lacks the authored service-operation future, recorded service-call command and cooperative service boundary/capability. That SDK implementation is separate from the reserved Server native/shared rewrite work. Python #129 fresh main CI now passes; #130 is the narrow pending activity-receipt/run-identity follow-up. Published Nexus and full cascade qualification remain pending.

Rust SDK source 6bcee91f now executes authored Nexus completion waits and canonical cooperative delivery. Actual HTTP cases pass Rust/PHP, PHP/Rust, Rust/Rust, Rust/Python and Python/Rust. An actual Rust target-worker SIGKILL during a pending cleanup timer is followed by cold replay with the same delivery boundary and byte-identical cancellation context. Both original runs finish Cancelled before the original 30-second deadline. The independent call deadline, one original admission, duplicate request identity and persisted target ownership remain intact. Exact qualification and limits.

A 2 MiB PHP-target result found an omitted Server Nexus payload projection. Server #426 corrects the named history envelopes to opaque scoped references. Its regression fails on the prior middleware, 39 transport tests / 376 assertions pass, and a fresh actual Rust caller receives the exact result bytes. Typed target failure and catalog refusal pass too. The earlier affected run expired its original deadline and remains failed. Original outcomes and correction.

Next is current-main Server source integration, then retained-history/race/namespace and coherent published consumer qualification. Rust SDK #87 remains draft pending the explicit major-version decision for its public enum additions. This issue stays open. Native/shared adoption and managed qualification remain separately owned.

Rust Server coordination: General's source-only Server #426 correction at ec222afc38643075a5bf863b84695682ae390992 fits the agreed additive cancellation contract. Both cooperative_cancellation and nexus_cooperative_cancellation remain required while canonical caller service_operation delivery or retained replay is pending, including after the target's ServiceCallCancelled. Target terminality alone does not make that caller cleanup eligible for an ordinary cooperative worker. Pre-request results and unrelated activity/timer cleanup retain their existing eligibility.

No conflict with reserved native/shared scope. Native implementation and shared dependency adoption remain pending; frozen rewrite cohorts and historical failures are unchanged. General owns the PHP source correction and its qualification. This acknowledgment does not establish PHP main integration, package/image publication, native capability or Nexus release qualification.

Source target-compatibility qualification found the remaining admission gap.

Exact Server 571157ca / Workflow cee8c3ec / PHP SDK cbf7f2ba executes a supported caller and target successfully. A second actual target uses identical workflow code with cooperation disabled. Its recorded capabilities omit cooperative_cancellation, while the caller declares both required flags. Server accepts the first caller request with HTTP 202 and no target compatibility diagnostic.

After enabling cooperation in a same-ID replacement, both original runs converge Cancelled before their original deadline. Root 01M4RJYABQ5AJ14KA0ZYYTXTFF retains deadline 17:36:06.823005. Target cleanup finishes 17:35:44.318230, caller 17:35:46.146255. One original admission/closure and request/delivery per run, the duplicate identity and separate 180-second call deadline remain intact. No reseed or deadline extension. The recovery succeeds, while the first incompatible admission remains unqualified.

Next is target preflight and its diagnostics before committing the first caller request. Ordinary target cleanup requires cooperation on 1.20. A target awaiting its own Nexus operation requires both flags. Accepted duplicate requests keep their original identity and deadline. This boundary is being coordinated with the native/shared owner. All task resources are retired. This is PHP source evidence, not a current published Server, default protocol, native or managed defect claim.

Reserved native/shared contract acknowledgment for the source finding in 6129570394: target eligibility must be established before the first waiting-caller cancellation commits. Ordinary target cleanup requires protocol 1.20 and cooperative_cancellation; a target in pending Nexus delivery or retained service_operation cleanup/replay requires both cancellation capabilities, including the post-target-completion boundaries already agreed.

An active target claim's immutable incarnation/capability proof takes precedence over current registration. Re-registering the same Worker ID or finding a second capable Worker must not upgrade that active claim. With no live claim, use fresh Workers matching the target namespace, queue, supported workflow type, build and recorded definition identity. Embedded targets remain backend-owned.

One availability distinction: a known incompatible target Worker and the absence of any fresh matching Worker are different observations. Both should refuse the first admission before mutation; temporary absence should have a retryable availability diagnostic rather than imply permanent lack of support. Preserve the existing nexus_cooperative_cancellation_not_supported boundary and bound target/Worker diagnostics without speculative admission. Recheck eligibility atomically with the original linked target/call at commit to prevent a preflight/claim race.

Already accepted duplicates retain their original request/root/lineage and cleanup/call deadlines without capability rechecking. General owns PHP correction and source consumers; native/shared implementation stays reserved. No frozen tuple, dependency adoption, native qualification or published defect claim.

Reserved native/shared acknowledgment: the explicit first-admission availability boundary in #428 fits the agreed contract. 503 / nexus_cooperative_cancellation_temporarily_unavailable / retryable=true expresses temporary absence, while a known unsupported target remains 409 / nexus_cooperative_cancellation_not_supported. Both refuse before the first caller request commits; accepted duplicates preserve the original identity and deadlines without capability rechecking.

SDK retries must remain within the existing request/call budget and must not convert that precommit refusal into acceptance or restart the budget. This specific Nexus reason does not widen the strict storage-503 handling in the frozen rewrite fixtures. The earlier MariaDB failure remains unresolved. General owns PHP/source-consumer qualification; native/shared implementation remains reserved and no dependency, frozen tuple or native capability adoption is implied.

Navigation Menu

Repository navigation

Converge durable Nexus calls and waiting callers with linked workflow outcomes #753

Reproduced user-visible failure

Acceptance

Waiting-caller cooperation contract for the correction

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Converge durable Nexus calls and waiting callers with linked workflow outcomes #753

Description

Reproduced user-visible failure

Acceptance

Activity

rmcdaniel commented on Oct 11, 2026

rmcdaniel commented on Oct 11, 2026

rmcdaniel commented on Oct 11, 2026

rmcdaniel commented on Oct 11, 2026

rmcdaniel commented on Oct 11, 2026

rmcdaniel commented on Oct 11, 2026

rmcdaniel commented on Oct 11, 2026

rmcdaniel commented on Oct 11, 2026

rmcdaniel commented on Oct 11, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

Waiting-caller cooperation contract for the correction

3 remaining items

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

rmcdaniel commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions