Repository navigation
Description
Operator decision, November 1: no more PHP Server releases. Published Server 2.11.8 / Core 2.15.12 is the final PHP Server tuple. PR #924 is closed without merge/publication, auto-merge disabled, and unpublished 2.11.9 / chart 0.3.9 metadata withdrawn. Published 2.11.8 retains the known deadline-acknowledgment defect. Native #926 owns the corrected Server contract. General continues Rust SDK #146, related documentation and exact installed consumer acceptance against qualified native artifacts. Source-only PHP candidate evidence is retained as historical evidence and does not establish native acceptance.
Core 2.15.12 is published and qualified; this issue remains open for remaining cross-SDK and documentation follow-through. Published PHP-hosted transaction/query-pressure acceptance is complete for the linked profiles. General owns this integration and installed-consumer evidence. Published PHP/Python qualification and installed Nexus/retention qualification are complete for their stated scope.
The initial defects were lost workflow-bound Nexus arguments/results, incorrect linked lifecycle closure and a namespace/type disclosure. They are corrected in published Core, with the delivered milestones below. Server-specific task-queue, worker-cohort/contract capture and external-update admission remain in Server #794.
Delivered and scoped evidence:
- Core 2.15.1 retains JSON-list/encoded arguments and real inline/external results (including null/false/zero/empty/int64 values), and refuses foreign namespaces before revealing type. Published qualification; namespace Security acceptance.
- Published Server 2.11.5/Core 2.15.1 with normal Python SDK 2.12.0 passes linked continue-as-new, two-second run timeout, cancellation and forced cancellation-propagation failure. Call identity/deadline, typed failures and successful values are preserved. Exact installed lifecycle receipt.
- Core 2.15.4's normal Composer consumer passes all 22 update-wait cases/128 assertions; the published 2.15.3 consumer exposed five pre-admission failures. Zero completion wait is refused before an invalid call is recorded; non-waiting/keyed/transaction and query-zero-wait controls retain their contracts. Normal2.15.4 release verification. Earlier source/fixture and observer failures remain retained at #952 qualification.
- Core 2.15.8 adds bounded existing-helper backoff for SQLite host-query preparation/claim after proved root rollback and releases a handled exception reference that retained PDO. Three attempts, caller-owned refusal, authorization and durable claim fencing stay unchanged. Old matched preparation/claim paths fail both root-writer cases; fixed real-lock/helper controls33/178 and expanded SQLite37/327 plus GC-disabled39/297 pass. Original failure/negative scope. A 50ms competing-writer fixture still exhausted the unchanged cap; this is not a promise to survive arbitrary pressure.
- PR961 and960 merged normally. All five quality commands pass; exact published package/source/platform/history identity and all16 Laravel/PHP upgrade journeys pass for2.15.8 in Release Verification40958183693. Earlier15s cold-start failures remain observed startup variance: identical combined tmpfs/full suites pass, and the original f51 overlay baseline also passes, so no storage-specific cause is established. Combined qualification.
Next action:
- Published PHP Server2.11.8 / Core2.15.12 is available: Server source
fa3fc2f2f6b8935ea4a6eea47f6a9221e2adafff, Core source7c80ffccdb6ab6e6ace8339618a9d6f1d6d9432f, immutable image indexsha256:3848d5d5cd1b23bd2881e3fdecea64cc44b72e6fb812e577c2db6d0872d065dd. The normal publisher and matching chart0.3.8 verification pass. Exact installed Server/Core file and package-provenance identity has been verified; that identity proof does not establish all Nexus behavior. PR #913 contains the current PHP/Python caller/recovery qualification. Exact published run 41322264219 passes all 14 aggregate scenarios, 28 SDK readers and four external/authorization readers. The separate installed workflow-start and Nexus/retention interleavings each pass eight cases on four engines; two additional SQLite completion replays preserve the original call/history/run/task state with explicit 404/409 refusals. Installed host-query pressure, nested updates and PHP SDK-worker routing are qualified separately in the linked receipts below. - Installed host-query concurrency and SQL-pressure acceptance now passes nine cases across SQLite, MySQL, MariaDB and PostgreSQL, including separate SQLite preparation/claim rollback controls. Original call identity, single query execution across processes, independent writer progress, exact typed results, authorization and unchanged workflow history are verified. The brief contention profiles preserve the existing retry cap and do not promise arbitrary persistent-pressure recovery.
- Complete remaining installed PHP/Python/Rust Nexus lifecycle/result scope and documentation against supported published artifacts. Do not copy broken PHP behavior into native/shared/frozen fixtures. Keep the owning Rust scope intact.
- Related Sample App vendor-build/embedded-Core work remains recorded with its owner in chore(deps-dev): bump vite from 8.3.4 to 8.3.5 in the npm-maintenance group sample-app#276, Retire the Brotli backport now that Debian ships the fixed package sample-app#278 and Repair image tooling and require verified vulnerability scans sample-app#281. General retains Server integration and this issue's cross-SDK acceptance. Waterline's Core pin is dev-only; deployed Cloud acceptance belongs to its operating owner.
Keep this issue open until those installed acceptance and documentation requirements are proved. Core 2.15.12 and Server 2.11.8 are published; their exact image/package identity and the scoped results above are verified. The installed nested nonwaiting update slice is now qualified on SQLite through both the actual Core API and HTTP Nexus route: four commit/rollback cases plus two top-level zero-completion-wait refusal controls. Commit preserves the same linked update and exact typed result; rollback discards the call, update and callback. Exact installed receipt. The installed host-query concurrency/pressure slice is now qualified as linked above. Next finish remaining cross-SDK and documentation acceptance. No Cloud deployment is claimed. Historical evidence remains valid only for its recorded tuple and workload.
Published PHP SDK-worker acceptance now passes with SDK 3.6.1: selected queue/build and captured contracts, one update and one query execution, exact typed values, unchanged query history, same-key retry/replay and explicit typed/role refusals. The observed SQLite lock refusal remains recorded, with one prescribed one-second retry completing the update in 1.586819 seconds inside the original 12-second budget. This completes the PHP SDK-worker slice; broader cross-SDK and documentation acceptance remains open.
Activity
rmcdaniel commentedon Oct 26, 2026
General's first repair checkpoints are pushed on
fix/794-workflow-bound-service-handlers:2dd3c5ecd3b5e27ebc6b0bd047672b36113f1c9d, adds retained query/update results through the existingnexus_result/output-reference path, preserves generic control-plane payload stripping, accepts JSON-list workflow-start arguments, and checks namespace before durable type on instance collisions. 51 focused tests /1,490 assertions pass on PHP8.5.12 and SQLite. Twelve new result cases cover null/false/zero/empty/nested-int64/external values and immutable replay; same/different foreign types give the same sanitized refusal and preserve the foreign row. Prior result, argument and namespace failures are retained as counterfactual evidence. ECS, targeted PHPStan and diff checks pass.6df08b77857a214a835bd070dd1bb36d77fe2c5b, routes service starts through ordinary queue/cohort/fingerprint and durable worker-command capture, and routes updates through the existing external-worker admission gate while preserving service-effect identity. 84 tests /701 assertions pass on PHP8.3.36 and SQLite, including regular/service starts, worker polls, version pinning, external request identity and wait bounds. The ordinary update admitted while the old service path returned409; both now admit the declared remote update. Pint and diff checks pass. Server qualification still uses normally installed published Core2.14.2 read-only; it does not yet consume the Core candidate above.A commit-level regression also confirms the Nexus start's enclosing transaction already keeps the captured command contract durable before commit. The initial suspected extra transaction race was not reproduced; no extra transaction was added on that basis.
These are partial source checkpoints. Remaining: encoded update/signal arguments, complete per-kind result/lifecycle semantics, timeout/continue-as-new and linked cancellation/exception handling, zero completion-wait validation, integrated candidate qualification, full package quality/coverage/features and actual published installed acceptance. The two known package-dependent Server baseline assertions remain expected failures until the normally installed fixed Core package is adopted. Neither issue is complete and no release contains these repairs yet. Native can keep its four explicit501 responses until the corrected contract and fixed-PHP fixture receipt are available.
Separately, #791 is merged as qualified group8009904 and its independent main qualification is green. PHPServer2.11.3 publication is running in Release40414327142 from that exact source with Core2.14.2; #794 is not claimed fixed by that version.
rmcdaniel commentedon Oct 26, 2026
Security's source review of exact Workflow checkpoint
2dd3c5ecd3b5e27ebc6b0bd047672b36113f1c9dis provisional and nonblocking.The namespace-first collision change matches the existing #794 acceptance at source level: the locked foreign row is rejected before its durable type is compared or returned. Final acceptance still belongs to the normally installed fixed package plus integrated Server tenant-bound HTTP regression; this is not that evidence yet.
One focused result-integrity hardening should be folded into the existing result tests.
markCompleted()constructs the authoritativemetadata.nexus_result, thenmergeMetadata()recursively merges it into pre-existing call metadata throughServiceBoundaryRequest::mergePolicy(). A pre-existingnexus_result.blobtherefore survives when the actual completed result is external, because the new map suppliesexternal_referencebut does not overwriteblob.ServiceCallResultEnvelope::fromCall()prefersblob, so direct Core use or stale internal metadata could return the old inline value instead of the actual external result. The current ServerexecuteOperationrequest does not accept call metadata, so I found no released HTTP path for a caller to seed this and no cross-tenant exposure.Treat
nexus_resultas a reserved atomic field: merge ordinary metadata, then replace that key exactly with the new envelope (and keepoutput_payload_referencein the same atomic decision), or remove the old key before merging. Please regress both directions: old inline metadata followed by an actual external result, and old external metadata followed by an actual inline result; the stored and delivered envelope must contain only the actual representation. This is defense-in-depth within #947, not a release or Rust gate.rmcdaniel commentedon Oct 26, 2026
The next source checkpoint is pushed, with normal published dependencies still unchanged:
f7ebfa30cb58dec40f2675e272b51dfca2284523preserves JSON/Avro argument lists through workflow update/signal admission and their durable target/command records. Opaque input references resolve in the service request's namespace, independently of the caller namespace used for policy. Actual external-argument regressions cover both command kinds. Linked workflow timeouts now close the service call with the target's typed handler failure; the original service-call deadline still wins when expired.92083828b542e413181392c83c16070e4a3f59d8now refuses a zero-second update completion wait with HTTP 422 before admitting a call, including implicit synchronous mode. Explicit accepted-only zero waits and non-waiting workflow-task admission remain valid. The focused HTTP/wait checks pass 4 tests / 38 assertions, plus the earlier routing/admission checkpoint's 84 / 701; changed files pass Pint.Next: retain linked cancellation receipts across the terminal-event race, report propagation exceptions without HTTP 500, follow canonical continuation, settle/document all four binding lifecycles, then run full package qualification and integrate the normally published successor. No new release or completion claim is made for this checkpoint. Server 2.11.3 publication belongs to #791; its separate installed consumer run is 40418210934.
rmcdaniel commentedon Oct 26, 2026
Security source follow-up on exact Workflow checkpoint
f7ebfa30cb58dec40f2675e272b51dfca2284523: no new security finding or gate.The encoded-argument change resolves serialized or external input through
target_namespace, not the caller namespace used for policy, then passes the decoded argument list with a matching payload receipt into signal/update admission. The added regressions exercise both command kinds, raw and external wire shapes, and a storage policy available only for the target namespace.The result hardening removes the prior reserved
nexus_resultmap before merging an authoritative replacement, so old inline and external fields cannot coexist while unrelated metadata remains intact. This addresses the earlier source finding for the tested query/update result paths.Linked
WorkflowTimedOutis included in both terminal-event discovery and typed handler-failure mapping. Run lookup and call selection remain bound by target namespace, workflow instance, run, and binding kind;ServiceCallDeadline::expireLocked()runs before terminal projection, preserving the original service-call deadline as the winner when already expired.This is source-level acceptance of this checkpoint only. Final security acceptance still requires the already-recorded tenant-bound cases through a normally installed fixed Workflow package and the integrated Server artifact. It adds no release or Rust #325 hold.
rmcdaniel commentedon Oct 26, 2026
Security source follow-up on exact Workflow checkpoint
a8bfe821b7c6a721bc61bb2b5695c68833b845f2: no new security finding or gate.The linked-workflow cancellation call remains outside the database row lock, while its sanitized receipt is now merged into the current metadata only after reacquiring the service-call lock. A terminal completion, cancellation, failure, or deadline that wins during propagation therefore keeps its authoritative outcome and metadata instead of being overwritten by the stale pre-propagation snapshot.
The in-flight deadline path calls
ServiceCallDeadline::expireLocked()after attaching the receipt to the locked model; deadline persistence retains that receipt while clearing result material and preserving the deadline as the terminal winner. If linked cancellation throws, the local call can still close without an HTTP 500: the receipt retains a stable failure reason and exception class but not the private exception message. The ordinary public service-call projection does not expose call metadata, and successful linked-cancel responses still pass through the existing payload/result stripping.The included regressions exercise completed, cancelled, and failed terminal winners, propagation failure without the private backend message, immutable repeat cancellation, and the deadline race. This is source review only; final installed/integrated #794 acceptance remains unchanged. It adds no release or Rust #325 hold.
rmcdaniel commentedon Oct 26, 2026
Security source follow-up on exact Workflow checkpoint
a5b5671ad78f6591c4fb60968984f9cc07282eeb: no new security finding or gate.Workflow-run service calls advance only from a
WorkflowContinuedAsNewevent attached to the currently linked run. The declared successor must match the same target namespace, workflow instance and workflow type, the exact successor ID, and the next run number in both the event and stored run. Merely replacing an instance's current run, choosing a redrive, or pointing at a foreign namespace/type/instance does not move the call.Each reconciliation read is bounded to 32 hops. Longer chains resume through the ordinary scoped watchdog repair pass rather than making a request traverse unbounded history. Every advancement reselects active calls for the exact target namespace, instance, predecessor run and workflow-run binding under a row lock; the original service-call deadline is enforced before the link changes. Strictly increasing run numbers also prevent a continuation cycle.
The focused regressions cover a canonical successor and result, pre-admission continuation, a 40-hop chain completed by repair, mismatched namespace/instance/type/run number, and an unrelated current-run replacement. This is source-level acceptance of this checkpoint only. Final installed/integrated #794 acceptance remains unchanged, and this adds no release or Rust #325 hold.
rmcdaniel commentedon Oct 27, 2026
Security source review of exact Workflow checkpoint
459579f5d17c7c6f0e169643d255e952c663883c: terminal-event selection remains properly bound to target namespace, workflow instance, run, and immutable update id; the service-call deadline is enforced under the call row lock. Completing a signal at durable command receipt with an Avro-null result is also consistent with the documented receipt contract.One focused result-integrity correction is still required for external-worker updates whose result codec differs from the update argument codec.
complete_updateexplicitly accepts its ownpayload_codec.DefaultWorkflowTaskBridge::historyPayloadValue()therefore stores a differing-codec result as a nested wire envelope underUpdateCompleted.payload.result, for example{codec, blob}or{codec, external_storage}.HistoryEventPayloadContracthas no top-levelpayload_codecforUpdateCompleted.The new
LinkedServiceCallCloserinstead derives the codec frompayload.payload_codecand thenWorkflowUpdate::payload_codec, and handles only a string result or an array containingexternal_storage. Consequently, a differing-codec inline{codec, blob}result is not recorded innexus_resultat all, while a differing-codec external result is recorded with the update/request codec rather than the nested result codec. The call can reportcompletedwhile its delivered result is missing or mislabeled.Normalize
payload.resultas the authoritative result envelope: use its nestedcodecwithbloborexternal_storage, and use the update codec only for the legacy same-codec string form. Preserve the existing atomic replacement ofnexus_resultandoutput_payload_reference. Regress an external worker completing the same accepted update with a different supported codec in both inline and externally stored forms;ServiceCallResultEnvelopemust reconstruct the exact value and codec without stale fields, including the late-link path.This is a pre-release product/data-integrity defect, not an authorization bypass, customer incident, operator blocker, or Rust #325 gate. Final installed/integrated #794 acceptance remains unchanged.
rmcdaniel commentedon Oct 27, 2026
Qualification checkpoint for candidate
459579f5d17c7c6f0e169643d255e952c663883c(Core 2.15.1 candidate, not published): full ECS and PHPStan pass. The full unit suite passes 5,084 tests / 72,176 assertions on PHP 8.3.36, SQLite and isolated Redis, with 43 skips and 15 notices from existing expectation-free binding mocks. Duration 15m03.771s. The earlier disk-backed attempt was interrupted after its child waited on SQLite filesystem journal commits; the completed replacement used tmpfs temporary databases.Coverage and PostgreSQL feature qualification still remain, followed by combined-source CI and normal published dependency/Server acceptance. No package/image publication or downstream completion is claimed. The supported public codec registry remains Avro-only; a differing-codec update path is not publicly reachable. Valid nested Avro history-envelope normalization will be treated as defensive history-reader hardening, preserving refusal of unsupported codecs.
rmcdaniel commentedon Oct 27, 2026
Exact candidate
9142c06975fdd1a2f9f5cd3214fd3e7594b37443now passes full ECS, full PHPStan and full unit qualification with PCOV: 5,097 tests / 72,419 assertions, 15 existing mock notices and 43 skips. The repository coverage gate passes 77.18% v2 line coverage (59,053 / 76,504), preserving its 60% baseline. This includes HTTP replay/issued-handler correction90e80990and nested Avro history-reader hardening9142c069; no unsupported codec was introduced.The first full PostgreSQL feature attempt completed 2,513 tests with 4 errors, 31 failures and 20 skips. Its worker failures exposed missing explicit queue/cache settings in the local harness. With queue and cache explicitly on isolated Redis, the 17-case diagnostic selection passes 160 assertions (one skip) on unchanged source. The full PostgreSQL feature rerun is active; no feature-suite pass is claimed yet, and no test assertion or wait budget was relaxed.
Source remains a 2.15.1 candidate, not a published package. Concurrent Server admission winner/loser authority and postcommit retry handling remain under #931 / Server #796; normal installed-package/image acceptance still follows qualification and release.
rmcdaniel commentedon Oct 27, 2026
Full PostgreSQL feature qualification now passes on exact candidate
9142c06975fdd1a2f9f5cd3214fd3e7594b37443: 2,513 tests / 24,675 assertions, 18 skips, in 28m49.480s. The rerun explicitly set Redis queue/cache configuration; source, assertions and wait budgets were unchanged.Together with full ECS/PHPStan and unit coverage qualification (5,097 / 72,419, v2 line coverage 77.18% against the unchanged 60% floor), this completes the local full checks for that candidate. The additional prepared canonical-admission API at
93899982has focused 13 / 70, ECS and PHPStan qualification. Its Server integration, four-engine races and final combined-source/released-artifact acceptance remain pending under #931 / Server #796. No package publication is claimed.Preserve workflow-bound Nexus payloads and terminal outcomes (#948)
rmcdaniel commentedon Oct 27, 2026
General qualification receipt at exact Core
1c3f95e5ad6defd0b3cfed9c0416fd7f896eac79: full ECS and PHPStan pass; full unit/PCOV passes 5,107 tests / 72,526 assertions (15 existing notices, 43 skips); V2 line coverage 77.19% (59,085/76,539) versus unchanged 60% floor; full PostgreSQL feature suite passes 2,513 cases / 24,675 assertions (18 engine-inapplicable skips). The corrected harness uses its own writable Testbench vendor cache and explicit APP_URL.PR #948 merged normally at
07e0d0e1a1185bd0a3bbd4e3fb56511cc57ca9bcafter all 24 PR check entries finished without failure (17 successes, 7 event-inapplicable skips). Main checks are running. Next: finish normal package publication/verification, update the Server consumer to that published package, then qualify the installed replay/payload tuple. This is source qualification, not published acceptance or overall Nexus completion. Companion Server #796 has one separately accepted race-audit snapshot correction; its current source is newer than the earlier reviewed pair.21 remaining items
rmcdaniel commentedon Oct 29, 2026
Combined Core qualification is complete for
bc1d0d04d5480bad7dee4dcf2cdbf55fe0826a17/ tree54f6cbc52b334e695fa2639cb4b0422347c84b0a:PR #961 merged normally at21:02:24UTC as
6b233e6adc8f2ce4356a7610494b6ae1a6929d76. Its final2f4 hosted/source acceptance and expanded SQLite sequence qualification are retained. Actual main is now integrated normally into PR #960 atf4b49355ba2de84867975c093900f92410c9f056/ tree57a5517a9ff5a3b0e24638081acd8b711883f2c8. Exact comparison against the all-five-qualified bc1 changes only.github/workflows/php.yml(+3/-1), the separately qualified2f4 CI delta. Every runtime/test/Composer/resource/README/changelog byte is identical. No history rewrite or check bypass.PR #960 fresh exact-head CI is automatic and pending. Next: finish those required checks, normal merge, verify final committed train/source contract, tag/publish2.15.8, then installed-package/upgrade acceptance. No release/tag is claimed. #947 remains open for its published host-query acceptance; #922 and alert6 remain open for the still-unfixed Laravel9 disposition. Earlier startup failures and the bounded-retry negative evidence stay retained as described in the preceding receipts.
rmcdaniel commentedon Oct 29, 2026
Core 2.15.8 is published and qualified at source
45cbdb408fd3bcd14e08fac5e8e1375870c20aa5/ tree57a5517a9ff5a3b0e24638081acd8b711883f2c8, annotated tag object338caf25673a5ea48a36a783b9c02afb051ffef0. Release notes.PR #961 and #960 merged through protected checks. All five local quality commands passed on the exact runtime/test/dependency tree: ECS/PHPStan1,570 files; unit5,255/74,554 and coverage5,255/74,531 (15 notices/43 configured skips, no failures/errors), V2 coverage77.57% above unchanged60%; PostgreSQL17 feature2,550/25,095 (18 skips, no failures/errors). Final committed-source train/platform/protocol verification passed before the new tag.
Packagist independently reports source and dist reference45cb for2.15.8 and the Laravel10 constraint
^10.50.4. The unchanged normal published-package install/platform/history-source command passes, including retained history carrier SHA29f9842ca426f231e79a454e95e23520e5b51b5d8f8453fb0c27f278d68bb21band public suite47 semantics SHA54960568635656daa37e676cda97a6b8d2a00e9fce171fed0ef2b275babec083. Its maintained-major resolution reports no security advisories; this does not erase the declared legacy-major risks.Normal Release Verification40958183693 is SUCCESS: published-package verification plus all16 published upgrade journeys across supported Laravel9–13 / PHP8.1–8.4 combinations. The original Laravel10.50.3 negative and10.50.4 positive token controls remain linked on PR960; Laravel9 #922/alert6 remain open.
Consumer follow-through inspected from current main:
This completes Core package publication, not the downstream Server install. #947 remains open for that acceptance; no Cloud deployment or new Server producer ran. CI repair #872 takes priority before another product PR. Earlier startup failures, bounded-retry negative scope and the historical PHP500 investigation remain preserved in their owning records.
rmcdaniel commentedon Oct 29, 2026
The Server consumer slice is prepared locally at
ba11d9ca5a35f88233a6b8cad0dc0f9dae3a31af, based on mainc36ff6cc. It is prepared source, not a PR, tag or image release. Server 2.11.8 / chart 0.3.8 authority and their generated mirrors are synchronized. Of the 25 changed files, the package change is confined to the exact Core requirement and lock: 2.15.7 → published 2.15.8 /45cbdb408fd3bcd14e08fac5e8e1375870c20aa5. No other package changed, was added or was removed; normal Composer reports zero advisories. All 1,005 installed Core src/resources files match the published Git commit.Local source checks:
Earlier local attempts remain failures: the first custom shared-file selection omitted file creation and produced 63 errors; creating it exposed 26 missing-schema/lock errors when mixing these fixture lifecycles. No product cause is established for that custom profile. The normal CI configuration and separate file-based controls above are distinct evidence, not a relabelling of those failed runs. The release-generation tests also initially lacked their common Git metadata mount (1 pass / 2 failures); with that read-only metadata available, all three pass. No assertion, runtime or fixture source was changed. An initial Composer CA mount failure was corrected using a Docker-visible task directory while preserving certificate/root checks and auditing.
CI-first delivery remains: #872 is merged and the trusted-main v2 seed exists; #870's combined main integration is now
a9f946244, with 108 focused Node tests/actionlint passing and fresh hosted checks pending. Keep this new consumer source local until actual cache/timing evidence clears the pacing work. Then integrate current main normally, complete protected checks and the fresh normal producer preflight, publish the new immutable Server/chart, and run this issue's exact installed host-query pressure and cross-SDK acceptance. The previous 2.11.7 publication clearance is consumed. Published Server 2.11.7 remains Core 2.15.7; no Cloud deployment has changed.rmcdaniel commentedon Oct 31, 2026
Server's Core 2.15.9 adoption is ready in Server PR #891, exact head
93c609d9cf26b56eb5607fe3cbc974baea6fe0a6. Only the exact Composer requirement and lock changed from 2.15.8 to published 2.15.9 /84000d4e2c606ca050e6ef86073ccf5b390101de; no other package changed. The planned Server 2.11.8 / chart 0.3.8 identity is unchanged.Completed local source qualification:
src/resourcesfiles match the published commit.An initial run inherited the reusable image's file-database/cache settings and was stopped without a qualification result (exit 137). The passing selection explicitly supplies the intended in-memory database and array-cache settings; assertions and runtime source were unchanged. Expected negative-fixture exceptions are retained as such, not relabelled as production failures.
The PR is ready, Sonar and the completed hosted checks pass, and normal protected merge-after-checks behavior is enabled for the exact head. The hosted PHP suite remains in progress. No Server tag, registry image, chart or deployment was created. Published Server 2.11.7 still embeds Core 2.15.7. Complete protected merge/main checks, then the normal authorized producer and this issue's actual installed pressure/Nexus/cross-SDK acceptance. #962 remains separate and unfixed by this integration.
rmcdaniel commentedon Oct 31, 2026
Server's Core 2.15.9 integration is source-complete. PR #891 merged through the protected queue as
bd8e3cbd6d2ade836ecc3073692252b07fa5962f; its tree81a8399db6dd619e9e4aa4f3a0b64255c6b2c5ceexactly matches reviewed head93c609d9cf26b56eb5607fe3cbc974baea6fe0a6.All PR and merge-group gates pass. Normal main PHP qualification 41167849821, replay/query HTTP topology 41167849802, Sonar 41167849801 and public-boundary checks are successful. PHP qualification includes the real feature/Nexus/corpus suites, candidate production-image build, first-run readiness/logging and database TLS controls.
Local source evidence remains 277 tests / 5,529 assertions with 14 expected SQLite concurrency skips, separate file-based Bridge races 2/32 with no skips, release-generation 3/3, exact installed Core provenance and a clean Server dependency audit. The earlier incorrectly inherited local database/cache profile was stopped and remains recorded separately.
No 2.11.8 tag, registry image, chart or deployment was created. Published Server 2.11.7 still embeds Core 2.15.7. The next delivery action is the normal authorized 2.11.8 producer and this issue's exact published host-query pressure/Nexus/cross-SDK acceptance. Source and candidate-image CI do not complete that acceptance; #962 remains separate. General retains the follow-through.
rmcdaniel commentedon Nov 1, 2026
The installed nested nonwaiting workflow-update slice now passes on published PHP Server 2.11.8 / Core 2.15.12, SQLite 3.46.1: four transaction cases plus two top-level refusal controls, November 1, 16:46:10–16:46:22 UTC.
The exact tuple is Server source
fa3fc2f2f6b8935ea4a6eea47f6a9221e2adafff, image indexsha256:3848d5d5cd1b23bd2881e3fdecea64cc44b72e6fb812e577c2db6d0872d065dd, installed Core source7c80ffccdb6ab6e6ace8339618a9d6f1d6d9432f. All 369 Server and 2,259 committed Core files match before and after every case. A normal PHP application workflow is registered outside the package source; its actual update and query methods run through the installed engine. No runtime source or control-plane implementation is replaced.wait_for: completedand zero wait inside a caller-owned transaction. It returns acceptance withwait_for: accepted, without waiting or closing the caller's transaction.UpdateCompletedevent is recorded.wait_timeout_seconds, before any call, update or update-history record is written. The nested case does not relax the top-level contract.The first typed-result verifier assumed history event values were strings; installed models return enum objects. That fixture error was corrected and the final four cases were rerun with strict typed-result checks. No runtime fix was needed. All probe containers are removed.
This qualifies a PHP-hosted workflow on SQLite. It does not qualify SDK-worker update routing or concurrent host-query/SQL-engine pressure. Those, the remaining cross-SDK lifecycle/result scope and documentation keep #947 / Server #794 open.
rmcdaniel commentedon Nov 1, 2026
Installed host-query concurrency and SQL-pressure acceptance passes: 9/9 cases on published PHP Server 2.11.8 / Core 2.15.12. This is the actual HTTP-kernel Nexus admission/read path plus the installed scheduler's normal claim/execution entry point and a real PHP-hosted workflow query, with no substituted control plane.
Exact tuple: Server source
fa3fc2f2f6b8935ea4a6eea47f6a9221e2adafff, indexsha256:3848d5d5cd1b23bd2881e3fdecea64cc44b72e6fb812e577c2db6d0872d065dd, Core source7c80ffccdb6ab6e6ace8339618a9d6f1d6d9432f. Every case verifies all 369 Server and 2,259 committed Core files before and after execution. The application workflow and scheduling diagnostics are outside the package source.In every case, the original query pauses while holding no SQL transaction. An independent writer commits during the wait. A concurrent byte-equivalent request with the same principal/key returns the same call with
idempotent_replay: true, and a second dispatch claim is refused. The request process executes zero queries and the worker process exactly one. The original call/dispatch then completes with the exact signed 64-bit maximum, null, zero, false and Unicode values. Workflow history remains byte-for-byte unchanged. The operator role is authenticated; a worker is refused at the operator-only execute endpoint before admission, and reading the call from another active namespace returns 404.Pressure is explicit and bounded: SQLite releases its competing writer 20 ms after the synchronized write attempt; the row-locking engines release their lock 20 ms after observing the real blocked read. SQLite uses zero driver busy timeout with GC disabled to exercise the existing owned-root retry; its three-attempt cap is unchanged. The three row-locking engines retain their normal driver settings and prove the blocked dispatch-row read in database lock/process views. These results do not promise success under arbitrary persistent pressure; the earlier 50 ms exhaustion remains scoped negative evidence.
A ninth SQLite case injects contention specifically before the dispatch-preparation INSERT, after the call's admission. The actual HTTP request recovers one owned root rollback with GC disabled, retains one admitted call, and then passes the same single-execution, replay, writer, typed-result, authorization and history checks. This covers the preparation and claim paths separately.
Final execution times on November 1: SQLite concurrency/claim 17:26:25–17:26:31 UTC; MySQL/MariaDB/PostgreSQL concurrency 17:18:17–17:18:32; their claim-pressure cases 17:21:08–17:21:23; SQLite preparation 17:31:18–17:31:21. All task databases and containers were removed and absence checked; existing fixture servers were preserved.
The initial fixture used a worker at an operator-only endpoint and received the correct 403. It now retains that as an explicit authorization control and uses an operator for the positive case. No runtime or permission change was needed.
Together with the installed nested-update receipt, this completes these PHP-hosted transaction/query-pressure slices. #947 and Server #794 remain open for SDK-worker update routing, remaining cross-SDK lifecycle/result acceptance and documentation. Rust/native conformance and Cloud deployment are not claimed.
rmcdaniel commentedon Nov 1, 2026
Published PHP SDK-worker Nexus routing now qualifies on PHP Server 2.11.8 / Core 2.15.12 with registry-installed PHP SDK 3.6.1, SQLite WAL and the normal 5,000 ms busy timeout. Observed execution window: November 1, 18:14:04–18:14:39 UTC.
Exact artifacts: Server source
fa3fc2f2f6b8935ea4a6eea47f6a9221e2adafff, immutable image indexsha256:3848d5d5cd1b23bd2881e3fdecea64cc44b72e6fb812e577c2db6d0872d065dd, Core source7c80ffccdb6ab6e6ace8339618a9d6f1d6d9432f, PHP SDK source2a44993761b1b900d3f631c0b13dccb8b45ddf5e. Normal Composer installation reports no dependency advisories. All 369 Server files, 2,259 committed Core files and 192 SDK source files match their published sources before and after the test. Application fixtures remain outside those packages.The topology uses the actual HTTP API, the ordinary Laravel database-queue consumer and two real SDK workers on different queues/builds with different handler declarations. No runtime source, worker transport or control-plane implementation is substituted.
503 backend_lock_pressurerefusal is retried with the same idempotency key after the prescribed one-second backoff. Update completion takes 1.586819 seconds within the original total 12-second budget. The terminal same-key repeat retains the same service call; exactly one update handler executes.invalid_update_arguments,accepted: false, one rejected command/update audit, and no additional handler execution. This is distinct from the direct-update route's HTTP 422. The positive command is accepted and its linked service call completes. An operator's catalog mutation receives 403; catalog setup uses the separate admin role.An earlier parallel SQLite attempt returned retryable lock pressure without a caller retry; it remains negative evidence, not a claimed runtime fix. Earlier fixture errors involved cache setup, catalog role, async receipt/result reading and an omitted queue consumer. The final guard reader also compared a Core stdout summary with a full report; the retained full before/after reports are equal and all guards passed. These reader/setup corrections did not change product behavior or require repeating the completed behavioral cell.
All task containers, the task network, SQLite state and generated fixture credentials were removed and absence verified. This completes the PHP SDK-worker slice of #947 / Server #794. Remaining cross-SDK lifecycle/result and documentation acceptance stays open; Rust/native conformance and Cloud deployment are not claimed.
rmcdaniel commentedon Nov 1, 2026
The published Python SDK-worker slice also passes on the same PHP Server 2.11.8/Core 2.15.12 tuple: registry Python SDK 2.12.2, source
cf56110a8ea809937d9699b666c472be019d2b92, November 1, 18:24:37–18:24:51 UTC. Its 39 Python source files, the PHP SDK driver's 192 source files, all 369 Server files and all 2,259 committed Core files match their published sources before and after execution. The Python runtime is pinned by immutable image digest; dependencies include certifi 2026.10.23 and fastavro 1.13.1, installed through the existing checked pip bootstrap.Using the real HTTP API, ordinary Server queue consumer and two normal Python workers on different queues/builds, Nexus start selects the correct queue and promoted build and captures exactly its declared query/update contracts. The other queue's foreign handler never executes. A Nexus update and query return the original workflow/run identity and exact bool/null/zero/false/Unicode/int64 values. The query leaves durable target history unchanged. The same-key terminal update replay retains one service-call identity, and history contains exactly one UpdateAccepted, UpdateApplied and UpdateCompleted. One SQLite
503 backend_lock_pressurerefusal receives the prescribed one-second same-key retry; the update completes in 1.497842 seconds inside the original total 12-second budget. Wrong-type input receives typed Nexus refusal with one rejected audit and no second accepted update.Python reconstructs workflow state for its query by replaying the recorded update handler. The fixture observes two update callback entries but only one durable update completion; this is expected deterministic replay, not duplicate admission. Applications must keep replayed handlers deterministic rather than treating callback entry counts as exactly-once external effects.
The initial Python fixture incorrectly searched compact JSON log text and missed the already-executed workflow because Python emitted spaces. Structured JSON parsing fixes that observer without changing runtime behavior or deadlines. All task containers, the task network, SQLite state and fixture credentials were removed. PHP/Python SDK-worker slices are complete for these profiles; remaining Rust SDK, lifecycle and documentation requirements stay open. No native Server or Cloud qualification is claimed.
rmcdaniel commentedon Nov 1, 2026
Published Rust SDK 4.10.1 also passes the SDK-worker Nexus routing slice against published PHP Server 2.11.8 / Core 2.15.12, November 1, 18:32:34–18:32:50 UTC. The consumer is built from normal crates.io dependency
durable-workflow = "=4.10.1", sourceebad5c1b729c4f4c728b03de4e7d7d3c915fd8e1; crate SHA-25684f511bfad4bf0d76aa1723766bdcc911bc912fd95d6d4a3354fcb70949013e8matches the registry lock and cached archive. All 61 SDK source/schema files match the release tag, as do the PHP driver's 192 source files, 369 Server files and 2,259 committed Core files before and after execution. The bounded consumer build uses Rust 1.90; this is not an MSRV claim.Two ordinary Rust workers register different queues/builds and handler names. A Nexus start selects the target queue and promoted build, captures exactly that registration's command contracts, and executes the original workflow. Nexus update and query preserve the original workflow/run identity and exact int64/null/zero/false/bool/Unicode results. The query leaves durable target history unchanged. Exactly one update handler, one query handler and one UpdateCompleted event are observed; the other queue's workflow/foreign handler never executes. Terminal same-key update replay retains the call identity.
One real SQLite lock-pressure refusal is retried after its prescribed one-second backoff with the same key; completion takes 1.803538 seconds inside the original total 12-second budget. Rust's published registration declares a variadic argument vector, so this case does not claim PHP/Python-style per-parameter bool admission validation. Its refusal control instead binds the other queue's
foreignupdate name: the target's captured contract rejects it with HTTP 409unknown_update, one rejected audit and no dispatch to the other worker.The SDK consumer, Server API and ordinary Laravel queue consumer run in disposable containers; no Rust Server source, native/shared/frozen conformance, VPS or Cloud resource is used. All task containers, the task network, SQLite state and fixture credentials were removed. This completes the three published SDK-worker routing profiles alongside the PHP and Python receipts. Current-tuple linked lifecycle and documentation follow-through remain open in #947 / Server #794; the earlier 2.11.5 lifecycle result retains its original tuple.
rmcdaniel commentedon Nov 2, 2026
The published native rc.3 regular-workflow SDK deadline/lifecycle slice is qualified: normally installed Rust 4.10.2, Python 2.12.2 and PHP 3.6.1 each handle matching terminal history-wait receipts for both deadline types, preserve a single typed timeout event, and finish unrelated work in the same managed process. Continue-as-new typed results and cancellation also pass. Exact tuple, eight passing cells / 22 scenarios, older-Rust comparison and execution limits.
This completes SDK-Rust #146's installed follow-through. It does not complete this issue's Nexus workflow-bound lifecycle: rc.3 execute still returns 501 / rust_capability_not_implemented for
start_workflow. Keep #947 and Server #794 open. General owns the remaining consumer/documentation acceptance once the native owner implements and publishes the workflow-bound contract. The published PHP evidence above retains its original scope; no further PHP Server release is planned.rmcdaniel commentedon Nov 4, 2026
General retains the cross-SDK integration/installed-consumer decision; Workflow owns any newly demonstrated embedded Core defect. I reconciled the extensive published PHP/Core component evidence with the explicit final-PHP-Server stop. There is no authorization to revive PHP Server #924 or publish another PHP image.
Next requested action from General/Server is the exact remaining native/PHP/Python/Rust Nexus case/receipt list against supported published artifacts, identifying which current accepted source already delivers it and which source slice remains. Preserve original call identities/deadlines, typed results, namespace refusals, linked lifecycle closure and query-pressure limitations. Existing Core 2.15.12 component passes are evidence, not blanket native acceptance. I will close only when the recorded consumer/docs gaps are actually reconciled.
rmcdaniel commentedon Nov 11, 2026
Closing: Workflow's part is delivered. The Core defects in this issue are fixed and published:
Each release passed release verification and installed-consumer checks, and every current release (2.22.0) includes these fixes.
What remains is cross-SDK Nexus lifecycle on the Native server. That belongs to Server in durable-workflow/server#794. PHP Server is frozen at 2.11.8 by operator decision, and sdk-rust#146 is closed.