[rmcdaniel]

Follow-through for the accepted SDK experiment audit.

Scope

The published Nexus workflow proves handled service failures. Add a separate actual uncaught-caller case in all four PHP/Python directions, shared plus tenant namespaces. The fixture rethrows the original service exception. Require one original ServiceCallFailed followed by one caller WorkflowFailed, the actual remote error type/message, unchanged endpoint/call/run/link/acceptance/deadline, distinct originals per case and clean worker shutdown within each original thirty-second budget.

The reader rejects caught workflow results, generic transport timeouts, retargeting, reused originals, duplicate terminal events, wrong cause, changed clocks and raised budgets. A genuine null call deadline stays null. Existing completion, handled failure, cancellation, cold/interruption, oversized and authorization cases remain enabled with unchanged budgets.

The legacy invocable-carrier aggregate cells remain separate and not covered. Their binding ends at admission until a carrier execution lane provides its own proof. This PR does not substitute workflow-run evidence for that contract.

No product runtime/SDK source, package/version, Composer, native/shared differential runner, schema/OpenAPI, frozen fixture or quality setting changes. The tuple remains published Server 2.9.1 / Core 2.6.1 / PHP SDK 2.5.0 / Python SDK 2.6.0. No new release or consumer rebuild is needed for qualification-only source.

Verification

Local PHP syntax, both Python fixture ASTs, Bash syntax, workflow-summary JavaScript syntax, thirteen reader tests and unchanged Docker isolation checks pass in disposable containers. The same complete-report reader is exercised by constructed direction/namespace/original-reuse controls before actual hosted data is available. No local application, database, dependency cache or paid host is held.

Current source dcb63a6b9d3eeb9881bd9d53c9ea775a3c6a651a, whole tree ca5d1df3aa555d4cbf3f26fb3f7302ec3804b43b, is pushed for fresh actual SDK and normal source qualification. Earlier reader-only 7e29f5a9 39111920715 finished successfully before the head advanced. It ran the existing published cases, not the new uncaught-worker cases. Delivery requires the current candidate checks and fresh exact-main acceptance. No earlier pass is carried across.

First actual outcome

Full candidate 39112558050 is failed. The first reader passes 24/25 tests; its new uncaught test expects input service name PublishedPythonWorkflowGreeter, but the published registry records canonical publishedpythonworkflowgreeter. Bounded assertion readback 39113289135 confirms the exact actual/expected difference. Core's contractName() and the Server command boundary deliberately lowercase service contract names. This is a new reader expectation error. The second external/auth reader does not execute after that failure; its prior qualified runs retain their own scope.

Prospective 949865ce46d6089cb9ad16ed61f7c6bbf3e1a4d5 / tree 07469f647b19724c0e07153564eeac4d29105b25 uses explicit canonical expected service names, adds a noncanonical-case refusal, and keeps actual values plus original identity/time comparisons strict. It also groups the four uncaught outcome notices into one: GitHub retained only ten individual notices from the first twelve, hiding two same-language summaries. Existing external/auth notices and data budgets remain unchanged.

The original ZIP digest was verified by 39113669560. Its index explicitly says the full authorization and uncaught reports were omitted under the unchanged 2 MiB report limit, so an offline counterfactual cannot qualify the corrected reader against those originals. The retained summaries show actual failed-caller observations but cannot replace the missing full report. The original run remains failed. Fresh workers and exact-source checks are required. Product runtime, SDKs and published artifacts are unchanged; no runtime defect is established by this observer failure.

The uncaught notice now carries only direction, process result and each original namespace/run/call/status/time, keeping all eight observations within GitHub's annotation limit. Detailed failures stay in the bounded outcome file and strict actual report reader. Existing report-retention and execution budgets are unchanged.

Candidate acceptance

Exact dcb63a6b9 / tree ca5d1df3 passes published SDK execution 39113849803, feature/source 39113849819, Sonar 39113849774 and both normal boundary checks. Nine complete outcome notices were read: eight distinct uncaught runs/calls all fail correctly, maximum 3.595 seconds within the original thirty seconds; the eight external and eight authorization originals also pass. The strict actual reader verifies the original typed remote/caller errors, one failed call and caller, canonical endpoint/service identity, unchanged clocks and clean worker shutdown. Sonar has zero new/accepted issues, zero new duplication and no ignored gate conditions.

This qualifies the candidate only. Independent fresh-main acceptance follows merge. The first failed run and separate legacy invocable-carrier gaps remain unchanged.

Fresh-main acceptance

Merged c38f8e34f80977d25e3d7c83227ca7a58d40d1a4 has the exact reviewed tree ca5d1df3aa555d4cbf3f26fb3f7302ec3804b43b. Independent published SDK execution 39114545513, feature/source 39114545566, Sonar 39114545532 and boundary checks pass. All nine complete outcome notices were read: eight distinct uncaught originals pass, maximum 3.869 seconds; all eight external recovery and eight authorization originals pass as well. External observers retain the original 128 MiB limit, peak 51,744,768 bytes, and exact typed bytes/hashes plus owner-200/foreign-404 checks.

The code and published tuple are unchanged from the candidate. No package, image, SDK or consumer release is required for these fixture/reader changes. The completed branch and raw exports are removed after terminal outcome review. The first failed run and the separate two legacy invocable-carrier cells retain their original outcomes. Conformance guide #197 records the supported command and its limits.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud