Skip to content

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

Closed

Description

@rmcdaniel

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.

Activity

  1. added
    kind:defectA public product behavior is incorrect
    priority:P1High-priority product or release risk
    completion:evidence-requiredClose only after all explicit acceptance and operational evidence is public
    on Oct 11, 2026
  2. rmcdaniel commented on Oct 11, 2026

    @rmcdaniel
    MemberAuthor

    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.

  3. rmcdaniel commented on Oct 11, 2026

    @rmcdaniel
    MemberAuthor

    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.

  4. rmcdaniel commented on Oct 11, 2026

    @rmcdaniel
    MemberAuthor

    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.

  5. rmcdaniel commented on Oct 11, 2026

    @rmcdaniel
    MemberAuthor

    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.

  6. rmcdaniel commented on Oct 11, 2026

    @rmcdaniel
    MemberAuthor

    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.

  7. rmcdaniel commented on Oct 11, 2026

    @rmcdaniel
    MemberAuthor

    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.

  8. rmcdaniel commented on Oct 11, 2026

    @rmcdaniel
    MemberAuthor

    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.

  9. rmcdaniel commented on Oct 11, 2026

    @rmcdaniel
    MemberAuthor

    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.

  10. rmcdaniel commented on Oct 11, 2026

    @rmcdaniel
    MemberAuthor

    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.

  11. rmcdaniel commented on Oct 12, 2026

    @rmcdaniel
    MemberAuthor

    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.

  12. rmcdaniel commented on Oct 12, 2026

    @rmcdaniel
    MemberAuthor

    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.

  13. rmcdaniel commented on Oct 12, 2026

    @rmcdaniel
    MemberAuthor

    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.

  14. 23 remaining items

  15. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    Embedded qualification #842 is merged at 5201f581e80b54c43d31a5777ce3b59748667340 after all applicable final-head checks and Sonar pass. Its actual normally installed RC profile passes twelve fresh same/cross-namespace originals, real cold database-queue processes, backend interruption, retained external payloads and read-only final-state checks as recorded above. The final qualification-only cleanup resolves all three Sonar findings without changing rules.

    Published PHP/Python and real Waterline inspection remain passing in 39092342740. The next gap is dedicated CLI inspection of result/failure, attempts and the original target: durable-workflow/cli#57 / #58 now implements the existing authenticated read boundary. Its command/output controls pass185 tests /607 assertions; exact hosted and published-binary acceptance are still pending. The separate CLI2.2.3 history-only cohort 39094079718 is active and cannot qualify the new command.

    I am preparing stable package candidates from the qualified runtime while that CLI gate runs. No stable tag, Server main promotion or broad platform-audit closure is claimed yet.

  16. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    Delivered for embedded Laravel and the PHP Server:

    • Workflow 2.6.0, Server 2.9.0 / Helm 0.1.176, PHP SDK 2.5.0, Python SDK 2.6.0, and CLI 2.3.0 are published and verified. Waterline 2.11.2 remains compatible without a product-code release.
    • Completion-waiting callers converge with the actual linked result, failure or cancellation. Original call, caller, target and deadline identities survive cold recovery. Explicit asynchronous admission remains available.

    Published-artifact acceptance

    • Core's normal installed-package audit and all 15 published Laravel/PHP upgrade profiles pass. Stable embedded observer #843 passes 12 fresh originals using 77 real queue invocations and 12 cold readers, including backend interruption, typed failures/cancellation and retained external results. Its read-only SQL audit passes.
    • Server publication 39097058515 passes exact image/source identity, bare first-run readiness, source-free Compose, protocol convergence and anonymous Helm installation. Published PHP SDK smoke 39097589496 passes normal installation and worker-scoped cooperative discovery.
    • Final all-stable cohort 39097610133 passes all four actual PHP/Python caller/service directions, cold recovery, backend interruption, terminal typing/cancellation and original-deadline assertions. API/browser inspection covers 24 original calls and 72 cases. CLI inspection preserves those original results, failures, attempts and targets, refuses 24 wrong-run plus 24 wrong-call selectors, and leaves histories unchanged. Cleanup passes. CLI #57 is closed.
    • Sample #241 updates the three affected Composer locks and shared artifact tuple. All applicable candidate and 22 fresh-main checks pass, including the nine-direction retry/recovery suite. Published image 39099128596 passes native amd64/arm64 startup/tooling/database qualification and main-channel promotion. Source is 77517190, whole tree 31eb156d, image index sha256:e24ae0a042c938c524592a2451411b27ab291a16c1f29aaae77c155efca59ef0.
    • Website #250 is live at fbaa81ec: all applicable candidate/main checks and actual Pages publication pass. The public stable-version manifest matches the committed file, and the new CLI/API service-call references work.

    The exact PHP source/image handoff preserves the native/shared/frozen boundaries. Cloud and native adoption remain separate. PHP handler API #16/#111 and Rust SDK 4 are unchanged.

    The broader platform audit remains open. Its historical admission-only aggregate retains two legacy not-covered cells; the separate strict actual-worker proofs above qualify the four Nexus directions. Earlier failed publication/input/fixture originals keep their original outcomes.

  17. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    The follow-through audit for PHP SDK#116 and Python SDK#116 found an uncovered acceptance boundary. The current published cohort proves inline terminal values, all four caller/service directions, failure/cancellation, original deadlines and cold/interruption recovery. Runtime-managed external Nexus results have a local Python replay test and separate embedded qualification, but the actual published PHP/Python caller-worker path with oversized arguments/results is not exercised by runner8528fa45. Its endpoint authorization case also uses the HTTP admission surface rather than an authored caller worker.

    Reopening #753 for this remaining acceptance coverage. Published releases, their passed checks and the inline execution results retain their original outcomes. No new product failure or native/Cloud cause is asserted.

    Next: extend the existing General-owned #425 qualification with separately identified actual PHP/Python caller/service originals for external payload delivery, cold recovery/retention and authorization refusal before dispatch. Preserve the current cases, original budgets, published tuple and all native/shared/frozen files. PHP SDK#116 and Python SDK#116 remain open until those outcomes and their source replay/compatibility criteria are verified. The broad .github#122 audit remains separate.

  18. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    The missing HTTP-worker external-payload acceptance is now implemented in a separate component based on the preserved #425 harness plus current stable main. Source 800479ed1 leaves PHP runtime, dependencies, native/shared/frozen paths and original cases unchanged.

    The new cases use the published Server 2.9.0 / Core 2.6.0 / PHP SDK 2.5.0 / Python SDK 2.6.0 tuple. Every caller/service direction sends an argument larger than 4 MiB, receives a larger typed result, kills the original waiting caller and starts a separate replacement process. The reader requires one original call, unchanged links/deadline, exact hashes/int64/null/Unicode, real persisted runtime references and authenticated owner fetch with unrelated-namespace refusal. Each new original has a 30-second budget. Existing recovery budgets remain unchanged.

    Local Node contracts pass 10/10, including 17 external-evidence corruption refusals. PHP/Python/Bash syntax and generated Compose validation pass. Actual published-worker qualification has been submitted and is pending. Authored authorization refusal is still separate unfinished work. No external delivery, authorization, release or aggregate acceptance is claimed from these source checks.

    Reports summarize large strings by size and SHA-256. This component reduces its hosted report retention to one day; raw large values are not a result artifact.

  19. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    The published external-payload experiment is failed at exact harness 800479ed1, run 39101244846, with Server 2.9.0 / Core 2.6.0 / PHP SDK 2.5.0 / Python SDK 2.6.0.

    All four same-namespace directions complete after killing and replacing the caller. Each preserves the exact 4,194,322-byte argument and typed result hashes, int64/null/Unicode, one call and a replacement-process exit of 0. Three cross-namespace originals instead time out, and their actual caller history returns HTTP 422 / external_payload_unsupported: “Server state contains an unregistered external payload reference.” The fourth cross-namespace original failed before observing the required waiting boundary and remains separately unqualified.

    Source review finds the target-owned external result envelope being copied into caller history without transferring it through the caller namespace's storage policy. The authenticated transport correctly refuses a reference that its namespace does not own. I am adding a package regression and correction at durable terminal delivery, preserving registry isolation, original call identity, deadline and duplicate delivery. Same-namespace behavior and failure/rollback controls are included. No foreign-reference lookup fallback or SDK credential workaround is proposed.

    The original remains failed. Prospective reader namespace corrections and authored authorization cases are separate, unqualified preparation. SDK #116 issues and this issue remain open until the corrected published package/image and actual SDK consumers pass.

    The original report was read on a bounded GitHub-hosted runner because local Azure transport timed out. The readback removed its downloaded data; its annotations retain the small observed outcomes. No native CI retrieval or product acceptance was performed by that readback.

  20. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    The cross-namespace external-result correction is now published as Core 2.6.1, source 1f72c41fa527685d9bcc75ea86f02ebe3cc9adfb, whole tree 7f76d9d9cd845cb966a72ac6a5b7eedbc6978495. Exact-main 39103284462 and all seventeen published-package verification jobs pass. Packagist source and dist match. Main Sonar uses that revision's real coverage and passes at 97.9% new coverage / 0.0% new duplication, with no ignored conditions.

    Normally installed embedded qualification #847 passes twelve fresh originals in shared and tenant namespaces, 73 independent queue processes, cold typed reads, external storage and backend interruption inside original budgets. Local application, database, dependencies and logs are deleted.

    This fixes newly recorded terminal deliveries. Already-persisted bad 2.6.0 history is not rewritten or repaired by upgrading. The original failed HTTP experiment stays failed.

    Server #487 now pins only Core 2.6.1 and prepares Server 2.9.1 / Helm 0.1.177; its source/image qualification is pending. Then #425 will execute the actual published PHP/Python oversized and authored-authorization cases on that exact rebuilt image. This issue and both SDK #116 records remain open until those missing acceptance paths pass. No native, Cloud or frozen-cohort adoption is implied.

  21. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    Reopened this issue because the required consumer rollout is still finishing. The runtime and missing SDK paths now pass:

    • Published Core 2.6.1 / 1f72c41f, Server 2.9.1 / c8b16baa, Helm 0.1.177, PHP SDK 2.5.0 and Python SDK 2.6.0. Exact Server index: 1631181c266cc74d70713e16b0688ea08b579cf2ed0e28f0ef5a3f3d786bc3d6. Package/source/image/anonymous Helm checks pass.
    • Final candidate 39107064615 passes eight real oversized originals and eight authored authorization refusals in all four PHP/Python directions, shared plus tenant namespaces. Oversized callers genuinely die by SIGKILL and complete in a new process on the original call/run/deadline. Actual integer type, int64 maximum, explicit null, Unicode and hashes match. All 32 owner reads return exact bytes/hash with HTTP 200; the 32 unrelated-namespace reads return 404. The read-only stored-principal audits and actual worker-token admin refusals pass. Every original keeps its thirty-second budget; the longest external case is 8.694 seconds and the longest authorization case is 2.969 seconds.
    • #425 is merged at c4ba3eec852f9132827423979bc48ff2d320a831, whole tree d15193fe02f5f5859cf857644e36ef6ef5540545, identical to qualified 538cae136. Every candidate check passes, including Sonar with zero OPEN/CONFIRMED issues. The prior 29184 SDK component also passes its actual cases; its notice-template boundary failure remains failed. The one-line formatting correction changes no business/observer assertion, resource budget or runtime.
    • Embedded #847 passes twelve normal-installed originals / 73 independent queue processes and its exact fresh-main build. Website #251 is deployed and its live version manifest matches committed bytes.

    Remaining before closure: Sample #242 source/image consumer rollout, final wrapper fresh-main checks, and the unchanged real-browser/CLI inspection on the new image. Waterline is a read-only consumer here; its Core dependency is development-only and its viewer image/SDK are unchanged. No new CLI or Waterline version is needed for the unchanged wire contract.

    The original failed records stay failed. Upgrading does not rewrite already-bad 2.6.0 histories. The broad Nexus aggregate's two admission-only cells remain explicitly not covered; .github #122 and native acceptance stay separate. PHP/Python SDK #116 records remain open through this final follow-through.

  22. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    Fresh-main wrapper result is separately failed at 39107690043. Its Python oversized cases and all eight authored permission cases pass. The two PHP external observer processes exit 255 before reporting: the retained stderr proves Allowed memory size of 134217728 bytes exhausted in the installed PHP transport stream reader. Child worker output is redirected separately. Original business state for those unreported observations is not established; no runtime/SDK cause or rescued-original claim follows.

    Observer-only #488, source c66bf4fb, compacts large snapshots when captured and releases decoded histories/handles between namespace cases. It keeps the observer at 128 MiB, now explicit, reports peak memory, and rejects a raised limit. Original worker settings, thirty-second case budgets, payload sizes and business assertions are unchanged. PHP syntax, eleven reader tests / 32 constructed corruption refusals and isolation checks pass. Fresh installed qualification 39108725862 is pending on the unchanged published tuple. The temporary readback branch, downloaded reports and local readback checkout are removed.

    Consumer progress: unchanged Waterline/CLI inspection 39107783086 passes its enforced 24 original calls, 72 API/browser cases, 36 screenshots, 24 CLI descriptions plus wrong-run/wrong-call refusals and unchanged-history checks. Sample #242 is merged after all twenty candidate checks pass; its new main/image consumer gates remain live. Website's current public manifest is deployed and exact. This issue and both SDK #116 records stay open through the remaining qualification; earlier passing components and failed originals retain their exact scope.

  23. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    The observer correction is now independently qualified on merged main, not just its candidate. #488 at 4887824317ad18854b183da978f59b8ae5c9ba4a / tree 20bbda056964511680c229afff26402d8af788d0 passes fresh SDK execution 39109351497, feature, Sonar and boundary.

    All eight final outcome notices were independently read: eight oversized killed/cold-caller originals and eight authored authorization refusals pass across all four PHP/Python directions. All 32 owner reads match exact bytes/hash with HTTP 200; all 32 unrelated-namespace reads refuse with 404. Every PHP observer stays at 128 MiB and peaks at 51,744,768 bytes. Maximum external time is 10.650 seconds within the original thirty-second budget. This changes observer retention, not the published worker/runtime, and does not rescue the old failed main run. Completed raw observer reports are deleted after review.

    Sample #242's immutable image and both architecture qualifications pass; Docker Hub/GHCR immutable and main reads agree on index f7e56298899dd427b2ae50c62141b6351369465ef1fccec2e69b5e09d2791616. Its separate fresh-main Compose smoke 39108731715 is still building the stack and has not executed its sample workflows. This issue and both SDK #116 issues remain open for that final consumer gate. No duplicate job or higher timeout is being substituted for the running original.

  24. rmcdaniel commented on Oct 18, 2026

    @rmcdaniel
    MemberAuthor

    Published Nexus acceptance and consumer follow-through are complete for the embedded/PHP Server and PHP/Python SDK scope.

    • Core 2.6.1 (1f72c41f), Server 2.9.1 (c8b16baa), Helm 0.1.177, PHP SDK 2.5.0, Python SDK 2.6.0, CLI 2.3.0 and Waterline 2.11.2 are published and verified. The Server image index is sha256:1631181c266cc74d70713e16b0688ea08b579cf2ed0e28f0ef5a3f3d786bc3d6. Core's exact main, all sixteen published upgrade profiles and installed embedded Qualify normally installed Nexus 2.6.1 in the embedded consumer #847 (twelve originals, 73 independent queue processes) pass.
    • The existing all-stable actual-worker/browser/CLI cohort qualifies all four caller/service directions, pending-to-terminal suspension, typed result/failure/cancellation, actual cold replacement, interruption and immutable original identities/deadlines. The new-image Waterline/CLI consumer passes its enforced 24 original calls, 72 API/browser cases, 36 screenshots, 24 CLI descriptions, 48 wrong-selector refusals and unchanged-history checks. These are workflow-enforced outcomes; its full archive was not independently downloaded.
    • Server #488 qualifies the remaining oversized and authored-authorization paths on the published tuple. Eight genuine oversized originals and eight worker-only authorization refusals cover PHP/Python in both same and tenant namespaces. Caller SIGKILL/replacement preserves one original call/run/link/deadline and exact hashes, integer int64 maximum, explicit null and Unicode. All 32 owner reads return exact bytes/hash with HTTP 200; all 32 unrelated-namespace reads return 404. Permission refusals record the original typed failure with no ServiceCallStarted, acceptance timestamp or linked target. The observer remains at 128 MiB, with original thirty-second case budgets. Candidate 39108725862 passes. Independent merged-main acceptance is recorded below.
    • Sample #242 aligns both Core-bearing locks and the artifact tuple. Candidate and independent main source consumers plus both published development-image architecture qualifications pass. Docker Hub/GHCR agree on immutable index sha256:f7e56298899dd427b2ae50c62141b6351369465ef1fccec2e69b5e09d2791616, source 3216b0dd, run 39108731728. Website #251 is deployed; its live stable manifest matches committed bytes.

    Independent final Server main 4887824317ad18854b183da978f59b8ae5c9ba4a / tree 20bbda056964511680c229afff26402d8af788d0 passes SDK execution 39109351497, feature, Sonar and boundary. All eight final outcome notices were independently read: sixteen actual originals pass, all permission audits succeed, and the PHP observer peaks at 51,744,768 bytes under 128 MiB. Maximum external duration is 10.650 seconds within the unchanged thirty-second budget. Completed observer reports are deleted after review; code, concise outcomes and original failed statuses remain.

    Sample's twenty-two latest main checks pass. Its first Compose smoke was cancelled at the original thirty-minute limit during a silent npm ci build step, before sample execution; teardown succeeded. One same-source job repeat passes all five actual embedded sample workflows and teardown without changing source, locks, inputs or the limit. Other passing main suites were not rerun. The original stall's cause remains unknown; that cancelled original is not presented as fixed.

    Compatibility limit: Core 2.6.1 fixes newly recorded cross-namespace terminal deliveries. Upgrading does not rewrite already-persisted bad 2.6.0 histories. The original namespace-delivery, pending-observer and memory-exhaustion failures retain their failed outcomes; no retroactive recovery is claimed.

    The broader .github #122 admission-only aggregate still has two explicitly not-covered cells and stays open. Native/Cloud adoption and the held SDK major/lifetime decisions remain separate.

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

    completion:evidence-requiredClose only after all explicit acceptance and operational evidence is publickind:defectA public product behavior is incorrectpriority:P1High-priority product or release risk

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions