Long activities without heartbeats are re-run every 5 minutes and never complete #878

Activity

1. rmcdaniel

   added

   bugSomething isn't workingSomething isn't working

   kind:defectA public product behavior is incorrectA public product behavior is incorrect

   kind:cross-repositoryWork spans more than one public repositoryWork spans more than one public repository

   priority:P1High-priority product or release riskHigh-priority product or release risk

   repo:serverOwned by the standalone server repositoryOwned by the standalone server repository

   repo:sdk-pythonOwned by the Python SDK repositoryOwned by the Python SDK repository

   on Oct 20, 2026
2. rmcdaniel commented on Oct 20, 2026

   

   rmcdaniel

   on Oct 20, 2026

   MemberAuthor

   More actions

   Accepted as a P1 product defect. Documenting a five-minute limit or asking every user to add progress heartbeats does not meet the optional-timeout contract. The published reproduction retains its original evidence; no current Cloud incident or shared historical cause is inferred.

   General owns the Core/PHP Server/SDK correction. The required distinction is activity execution and declared timeouts, task-lease ownership, worker loss, and user-authored progress heartbeats. A longer hard-coded lease alone would postpone recovery and preserve the defect. The fix must keep a live execution's original attempt authoritative without requiring business-code heartbeats, fence a lost/replaced worker, apply a bounded and inspectable redelivery policy, and record expiry/redelivery/late-refusal decisions without unbounded liveness history. Coordinate that last boundary with #870.

   First source regression will establish live long activity versus actual worker loss under controlled clocks, then the released-artifact gate must run the requested real six-minute no-heartbeat activity and killed-worker case. DW_ACTIVITY_TASK_TIMEOUT needs one effective documented configuration path. Python #171's separate event-loop fix and #177's pending 2.6.2 release do not establish or resolve this lease defect; the published cohort must identify its exact SDK and Server tuple. Existing #216 work and other owners' branches continue independently. Native parity belongs with Server #325 and will receive the settled exact contract, rather than a speculative runtime change.
3. rmcdaniel commented on Oct 20, 2026

   

   rmcdaniel

   on Oct 20, 2026

   MemberAuthor

   More actions

   The first Core source slice is tests-first 325358d on published main dda951d. It isolates two parts of the defect: lease expiry bypasses the stored retry/backoff policy and leaves no canonical retry/failure history for the original attempt. This does not replace the required automatic lease-maintenance fix or the real six-minute published acceptance.

   The initial SQLite invocation reaches and fails the retry-policy assertion (Running instead of Pending), then its second case fails setup after Testbench falls back to an in-memory database because the requested file did not exist. The corrected observer creates its own SQLite file before boot and runs the same source/assertions. No product behavior, timeout or assertion is changed to repair that setup.

   The phase uses a uniquely named ephemeral PHP test container, borrowed dependencies and its own temporary SQLite file, with actual removal by 20:00 UTC. No paid host, provider change, foreign cleanup or source-file hold is requested. Normal source review and the complete runtime fix remain ahead.
4. rmcdaniel

   added

   status:in-progressApproved work is actively being implemented or validatedApproved work is actively being implemented or validated

   on Oct 20, 2026
5. rmcdaniel commented on Oct 20, 2026

   

   rmcdaniel

   on Oct 20, 2026

   MemberAuthor

   More actions

   The first recovery component is draft #879 at 221233d3b578ff1cf6cc412c4b59ef47cfc0ce32: 75 cases / 543 assertions pass, with one explicit row-locking-only test skipped on SQLite; focused PHPStan and ECS pass. Its temporary application/database resources are removed. This is not completed #878 acceptance.

   The next product component separates runtime liveness from application progress:

   • A live original activity attempt can renew its short worker lease without writing a heartbeat/history event or moving its authored heartbeat/start-to-close/schedule-to-close deadlines.
   • Renewal must validate the current task, execution, attempt, namespace and owner, refuse an expired/replaced/closed attempt, and return an explicit acknowledgement with the original identities and current server/lease times. Read-only status remains read-only.
   • Use an additive optional Core renewal contract so custom implementations of the existing ActivityTaskBridge are not broken. Actual Server support will be discovered explicitly; an absent/false/unknown capability cannot be assumed from a version string.
   • The Server's documented DW_ACTIVITY_TASK_TIMEOUT must reach the real activity lease policy. Embedded configuration must reach the same resolver. A larger lease alone is not the fix.
   • SDK supervisors and the embedded runtime must maintain liveness independently of user callback heartbeat calls. A worker that dies cannot keep renewing, and loss of renewal must retain the recorded retry/expiry policy from the first component.

   Current native/frozen actors and schemas are unchanged. Actual renewal implementations, network races, default/disabled/timeout controls and the published six-minute plus killed-worker cohorts remain required. This source phase uses isolated local fixtures and retains earlier failed observations; no release acceptance is inferred.
6. rmcdaniel commented on Oct 20, 2026

   

   rmcdaniel

   on Oct 20, 2026

   MemberAuthor

   More actions

   Core lease work remains draft #879, now exact 98f33052149395b9583e363db3fb28e9d0a53cb5 / whole 80fceb7e2c8449a362177e32a195fd1d27ae3cff.

   The combined source adds recorded retry-budget recovery, an optional runtime lease-renewal role, effective duration configuration, and a current-lease operator view that preserves terminal history. Renewal does not manufacture application heartbeat progress or extend authored deadlines. A new actual two-connection PostgreSQL regression proves the preceding repair waited 5.015 seconds while retaining its run lock; the correction refuses contention.

   Local evidence: 116 bridge/lease/repair/view cases and 1541 assertions PASS; a separate overlapping 75-case timeout/repair selection and 543 assertions PASS, with one explicit SQLite row-locking skip. PostgreSQL 17.11 and MySQL 8.0.46 each pass 17 focused controls/79 assertions; PostgreSQL additionally passes five existing heartbeat/worker/watchdog concurrency cases/107 assertions. Focused PHPStan/ECS pass. Earlier failed/interrupted controls remain described in the PR, including the local SQLite lock and fixture configuration limits; no later pass establishes that failed run's cause.

   All temporary local applications/databases/tools are removed at 20:22 UTC; both database processes and Redis exited 0 without OOM. Hosted whole-head qualification is fresh and pending. Server routes/configuration and actual PHP/Python/Rust/embedded worker maintenance, original-budget acknowledgement, and published six-minute/killed-worker acceptance remain required. This is not a completed #878 fix, native capability, frozen-cohort adoption or released artifact.
7. rmcdaniel commented on Oct 21, 2026

   

   rmcdaniel

   on Oct 21, 2026

   Last edited by rmcdaniel

   MemberAuthor

   More actions

   The next #878 source correction is pushed at 80f9ec32284a0546067c25c068b9d6b6e312359e, whole tree dfd1b93fc3fe0731247770eb947dc305531eb11e, separately from the still-incomplete #879 head.

   The prior preparation captured the application's heartbeat deadline forever. Two new counterexamples fail on that source even after a successful renewal observes committed progress. The correction separates the renewable progress deadline from the original close, schedule-to-close, run and execution deadlines. It accepts only newer stored heartbeat identity/time and the exact originally recorded heartbeat interval, within the still-live original claim. UTC6 precision, monotonic request latency, original owner/attempt and lease lineage remain required. Replayed or invalid progress cannot acquire a fresh window, and neither an expired heartbeat nor an expired lease can be revived.

   Runtime renewal reports the stored heartbeat deadline without changing progress, execution rows or history. The actual SQLite control first records application progress, then renews the lease and proves that the reported progress is exact while the execution and history stay unchanged. This is not a synthetic heartbeat or a business-timeout extension.

   Actual focused results on PHP 8.3.35 / Laravel 13.38.0 / PHPUnit 12.5.40: 42 claim tests / 124 assertions, seven SQLite bridge tests / 54 assertions, focused ECS and PHPStan all pass. The test-first parent has two failures among 42 claim tests. Earlier local bridge invocations inherited a nonexistent PostgreSQL/Redis test environment, then used an in-memory database that did not survive the harness's connection reset; both are retained as environment-blocked results. The existing harness passes using an isolated file-backed SQLite database, without changing product or test expectations.

   All task-installed dependencies, generated lock/cache, SQLite files and tool containers are retired; borrowed tooling is preserved. This is source preparation, not a published fix or full matrix. Automatic embedded/SDK lease maintenance, original-attempt race/worker-loss coverage and genuine longer-than-five-minute published-artifact acceptance still need implementation and qualification. Those are the next actions; #878 and #879 remain open.

   The source is now integrated with qualified Core main at 21db5b7d315265674a0c6388257095462d903dd0, whole tree c3f538cf4e90a214fb83ca3df25abeae74a5a122. The five lease/bridge/interface/test files are identical to the tested 80f9 component. No whole-tree result is transferred across that integration.

   Authenticated Server transport and affirmative discovery are now prepared in Server draft #564, head cf465b0a6b9926d41555a8d212869d87c43fe53f. The optional worker-only route retains namespace, original attempt/owner, role and worker-session authority. It maps validated activity lease configuration into the new Core resolver, and refuses an unsupported bridge. It records no business heartbeat or history. Poll server time is outside the cached task so unchanged exact-redelivery assertions remain valid.

   The explicit 21db Core source cohort passes 79 selected Server tests / 2,578 assertions. An independent ordinary locked Core 2.8.0 cohort, with no source overlay, passes 70 compatibility tests / 2,484 assertions, plus the separate unsupported-custom-bridge control (one test / four assertions). These selections overlap. The earlier missing environment-contract entry and misplaced cached-task clock failures remain recorded in that PR. Composer and its lock are unchanged, so this is not published dependency adoption or an enabled released capability.

   The Server phase's 197 MB vendor and generated caches were verified absent at October 21 01:29:52 UTC, ahead of its 01:35 retirement boundary. No task application, database or provider resource remains. Source CI, current wire documentation, automatic workers and published-artifact acceptance remain unfinished.

   The corresponding Python client primitive is now prepared in SDK Python draft #183, source 6087870da50b2fb1f515c49c932104a25db7ee35. It requires affirmative optional capability discovery, sends the exact claim using worker credentials, and bounds discovery plus transport/retries within one caller window of at most five seconds. It does not record application progress or claim that HTTP success alone renews local outcome authority.

   Ten tests first fail on the missing method. The final 17 focused cases and the complete existing client file pass together, 217 tests, with focused Ruff passing. The real client header path preserves X-Namespace, worker auth and original identity. Stalled discovery and transport cancel within the supplied window; missing/false/malformed capability and invalid identity/window controls refuse. Initial tooling lacked pytest, a temporary filesystem was not executable, one fixture used the wrong header name and a source-only broad invocation lacked installed package metadata; those unsuccessful observations are retained in the draft. Final verification uses an ordinary installation of the exact source in a disposable environment, without changing the existing package-identity assertion.

   This adds transport only. Automatic Python worker scheduling, original monotonic grant validation and outcome fencing are the next implementation step, alongside the matching PHP/Rust/embedded work. No published fix or longer-than-five-minute acceptance is claimed. All Python task containers, temporary installation and tools are retired; only clean source remains.

   The existing Core draft #879 now admits d863245ac3f5a24088038de51d4d2881ad05e494, whole tree 016c959e152d482b2904c04cbb66ac7e5a049271. The only change from 21db is two immutable replay histories for recorded lease-loss retry and terminal failure/recovery. Both pass the actual cold replay runner (2 tests / 47 assertions); the preceding history contract rejects both on the new lease-loss diagnostic fields. The entire unit replay consumer passes 67 tests / 2,496 assertions.

   The normal full regression-policy command passes against qualified main 9776f4a4 with counterfactual enforcement enabled. Replay evidence grows from 68 to 70, and both new fixture paths independently fail the base consumer and pass the current consumer. The earlier repository failure and the local missing-vendor/Redis setup failures remain distinct. No fixture, guard, timeout or expectation was relaxed. This resolves the missing local corpus evidence, not the remaining automatic-maintenance product work; fresh hosted checks for d863 remain pending.

   The replay phase's dependencies, generated files, counterfactual source, temporary tool image and isolated Redis/database/network state are all verified absent at October 21 02:16:51 UTC, ahead of the recorded 02:45 boundary. Active source is clean; borrowed tools and other contributors' resources are preserved.

   Automatic Python worker maintenance — October 21

   Python draft #183 now admits dfe10e778b37fde0d3ab03bfebdf8dcfb70217d1, whole tree 38cb1f410dcaef232d1a9a13599f44d9d52754ea, including qualified Python main ab7ee6f8. This is unpublished source qualification, not released long-activity acceptance.

   Affirmative capability enables validation of the original task, run, execution, attempt and owner before payload loading. A bounded confirmation distinguishes an empty long poll from transport of an actual lease. Automatic maintenance then covers payload loading, async/threaded callbacks, result encoding/uploads and every terminal HTTP attempt, including retries. It preserves original business deadlines, cannot revive expired authority and records no application progress. Only an actual acknowledged application heartbeat advances its recorded progress interval. A cancelled synchronous callback retains its physical executor slot until the thread really exits; cancellation is not claimed to stop arbitrary user code.

   Five tests first fail against the earlier API-only source. A later application-heartbeat control exposes stale local progress authority, and overlaying the preceding 5e11e029 client onto the final source reproduces the empty-poll clock failure. The final exact source passes 65 focused cases, and the combined client/worker/query-authority/renewal/telemetry selection passes 557 cases with two skips. Selections overlap. A normal disposable installation is used, with all 36 production files verified identical before and after. Focused Ruff, strict mypy on four affected source files and diff checks pass.

   The first broad fixture wrongly demanded one completion attempt despite legitimate retries before the deadline; it now verifies every actual attempt timestamp. Another mock anchored its execution clock before client bootstrap and correctly refused an expired claim; it now creates timing at actual claim admission. Those unsuccessful observations are retained separately, without relaxing product timeouts or refusals.

   The owned tool container stopped at 02:57:36 UTC, before its 03:00 retirement boundary; independent subsequent inventory confirms it absent at 03:01:32. Its installed source, tools and caches lived in container tmpfs. No application/database/provider stack or paid host was admitted, and borrowed images are preserved. Only clean source remains.

   Remaining acceptance includes Server projection of original run/execution deadlines and current API documentation, actual database and worker-session races, matching PHP/Rust/embedded maintenance, and genuine published longer-than-five-minute and killed-worker controls. #878 remains open; no native/frozen dependency adoption or released capability is claimed.

   Original workflow deadlines and recorded retry budgets

   Core draft #879 now admits 0014655dde34635bc763ad43e4a182b6351fb03a, whole tree 522161b141f0ebdf401b4fa823b169eb8ebc76ab, incorporating qualified main 2bc1ba0b. Server draft #564 admits 38678857226fabef145ddfb5d40278dd5b51a225, whole tree c4d71d246c502d99231d758001aa41695feeb7a1. Both remain unpublished drafts; the ordinary Server Core 2.8.0 lock is unchanged.

   Five Server counterexamples first fail on missing original run/execution timing and accepted expired renewal/outcomes. Two further controls prove that an external-result read can cross a workflow deadline after successful preflight. Two Core unit controls independently reproduce the live-lease overrun. The Server now copies original UTC6 run/execution bounds into poll/status metadata and refuses already expired work before payload resolution; Core checks the original locked run again during heartbeat/renewal and publication, including after payload preparation. A live lease does not reset business timeouts.

   Actual qualification: 187 Core cases / 1,311 assertions with file-backed SQLite/shared Redis, and an overlapping explicit Server/Core selection of 170 / 4,594. Ordinary locked Core 2.8.0 compatibility separately passes 111 / 4,323, excluding the two new under-lock crossing cases that need the Core correction; the unsupported bridge control passes 1 / 4. Focused Core PHPStan, ECS across all changed PHP, Server Pint and diff checks pass. This is local source qualification, not a fresh all-database or published-artifact result.

   The earlier Core hosted ECS refusal is corrected. Its portable-abandon CI failure is reproduced: the fixture recorded one attempt but expected another after lease expiry. Recovery now explicitly records two attempts, and a complementary one-attempt control proves exhaustion, failure history and unchanged parent closure. Both pass (2 / 27) within the broader Core selection. Initial local Testbench resets used an in-memory database, then inherited unused PostgreSQL defaults; the actual file-backed harness with environment propagation passes. No production retry allowance or assertion is relaxed, and old failed CI remains failed.

   The reference and observation guides now describe the optional renewal route and original deadline map. Current machine-readable OpenAPI coordination, matching automatic PHP/Rust/embedded behavior, real network/session races and published six-minute/killed-worker acceptance remain open. Fresh exact-head gates are independent. Python #183's Sonar gate passes but has actionable source/test findings; its durable corpus guard is failed and still needs diagnosis. No full acceptance is inferred from other passing checks.

   At October 21 03:32:39 UTC, the phase's tools container, Redis, private network, temporary Core harness/dependencies/SQLite, copied Server vendor, generated caches/logs and downloaded diagnostic logs are verified removed, ahead of the recorded 03:40 boundary. Clean source worktrees remain; borrowed images and inherited source/dependencies are preserved. No application stack, paid host or provider resource remains from this phase.

   Canonical Python discovery and source quality

   Python draft #183 now admits 437a6aa7e6a46d0026bc8272602b3a33d0979443, whole tree caf6e199ac96f7295c921b63edf33ad8e65ccc8e, on qualified main ab7ee6f8. One new counterexample proves that affirmative capability in the actual Client cache did not fence a delivery missing original authority when a separate Worker flag was unset. Three legacy/malformed controls pass on that old source. The correction uses the same canonical Client discovery as actual renewal requests and removes the duplicate Worker registration state.

   Current focused authority/renewal/worker selection passes 69 cases. The overlapping broader selection passes 561 cases with two skips, using a normal source installation on Python 3.10.22; all 36 installed production files match before and after. Focused Ruff and strict mypy on all four production files pass. Exact-head Sonar 39540797101 and the app check now pass; independent API review proves all nine source/test findings CLOSED/FIXED, zero OPEN/CONFIRMED and zero new issues, with new-code duplication 0.0%. The individually resolved asyncio.timeout suggestion remains unsuitable for supported Python 3.10; no rule, profile or threshold changed.

   The unchanged official corpus validator locally reproduces the original classification failure on the preceding source. Removing duplicated registration state also restores the correct unrelated replay classification: the current official command passes against ab7ee6f8, codec 42 to 42 and replay 63 to 63, without any fixture or policy change. All 54 validator self-tests pass. The original hosted failure remains failed, and fresh exact-head CI/Sonar are queued independently; local results are not substituted for those gates.

   The separate tool container stopped at 03:51:02 UTC, and independent inventory verifies it absent at 03:51:53, before the 04:20 boundary. Its tmpfs installation, dependencies and caches are gone. The idle tool shell required exit 137 after successful test completion, not an application shutdown. Borrowed tools and every foreign resource are preserved. No local application, database, paid host or provider resource was admitted. #878 and all three drafts remain open; genuine published long-activity and killed-worker acceptance, matching other runtimes and full wire/race qualification remain required.

   PHP renewal transport component

   New PHP SDK draft #202 holds 7ab48ce24da7887c206bd1661ce8db3ee3802262, tree 2c9c47fa609615be2dc2fdf8249a647d1e3cb598, on qualified main 222e27e. It adds capability-gated runtime renewal with worker credentials and original task/attempt/owner values, bounded discovery plus renewal within five seconds and any earlier caller deadline, and no application-progress fields. A late HTTP success cannot return a grant, and an expired lease refusal is retained without another claim. The future automatic worker layer must still validate the returned original identity and actual grant; HTTP success alone is not authority.

   Tests-first b4c1658 has 18 actual missing-method errors before implementation. The final 22 renewal cases are part of the overlapping 282 tests / 1,054 assertions PASS on PHP 8.3.35 / PHPUnit 10.5.66 / Guzzle 8.3.0 / Avro 1.12.2. A normal Composer installation has all 172 production files matched against source after testing. Focused repository-level-6 PHPStan on both changed source files and diff checks pass. Initial analysis was blocked by a 128 MiB tooling limit; a later unintended whole-SDK analysis lacked optional tracing/Monolog symbols. The intended two-file command passes with 512 MiB inside the existing resource ceiling, without suppressions. Fresh hosted checks remain independent.

   The only PHP tool container stops at 04:05:42 UTC, independently verified absent at 04:06:06, before its 04:50 boundary. All tmpfs installation/tools/caches/raw logs are gone; borrowed tooling is preserved. No application, database or paid/provider resource was admitted. Automatic PHP scheduling, matching Rust/embedded maintenance, original-authority races and published long-activity/worker-loss acceptance remain open; no package, schema, native/frozen or full #878 acceptance is claimed.

   Current hosted qualification and source review

   Core 0014655d now has its final hosted build PASS, with 11 OPEN Sonar source findings requiring review in the remaining maintenance work. PHP 7ab48ce has Sonar app PASS / 0.0% new duplication, with one literal-deduplication finding to fold into automatic maintenance. Neither is a zero-finding claim.

   Server 386788572 has a terminal failed PHP feature suite and source aggregate in run 39538649933, job 119022621732; performance/growth, repository, Sonar and boundary checks pass separately. A bounded PHP job-log fetch timed out at Azure, so the exact failing assertion and cause are not independently established. The explicit source cohort and narrower stock Core 2.8 compatibility remain their own earlier results; they do not turn this failed qualification into a pass. Three Server Sonar findings also remain open. No original is rerun or expectation weakened, no full acceptance or current-release cause is inferred, and all drafts remain unpublished.
8. rmcdaniel commented on Oct 21, 2026

   

   rmcdaniel

   on Oct 21, 2026

   MemberAuthor

   More actions

   Related to "losing the worker is still detected within a bounded time", from later reviews of activities left behind at worker shutdown.

   • A clean deregistration recovers the worker's leased workflow tasks but not its leased activity tasks. Activity leases are released only when a replacement registers with the same worker id. Kubernetes pods with generated ids never do that.
   • A Python worker whose callback outlives shutdown_timeout keeps its registration.

   Either way, an abandoned activity waits for its 5-minute lease, or its heartbeat timeout if one is set, before another worker can take it. Please make deregistration release or settle activity leases the same way it does workflow tasks. Please also have the timeouts guide state how long an abandoned activity waits, with and without a heartbeat timeout.
9. rmcdaniel commented on Oct 21, 2026

   

   rmcdaniel

   on Oct 21, 2026

   Last edited by rmcdaniel

   MemberAuthor

   More actions

   Worker deregistration and original activity authority

   The added scope in comment 6308978568 is reproduced: tests-first Server 53759639c has five failures. Both deregistration routes leave the original attempt running; exhausted retry budgets are unsettled, and the fenced receipt can complete without activity settlement.

   Prepared Core 16e5f2ab884a99f9a21312d8e12d85b993cccb3c / tree adb46dd0ccf6cb59e3fab47f918cb803622f5b17 and Server c7765d2e75acab0d2571ccc421a21342ad93aab5 / tree e6c9d434e0da4f41d630892cabc4cfc0a85a39b6 are pushed separately on prep/878-worker-departure. Core runtime bytes match tested 52650566; the successor only completes the history-field documentation.

   The stopped registration/incarnation remains fenced while Core rechecks the original task, namespace, owner and attempt generation under canonical locks. It records explicit worker departure and applies the recorded retry/backoff or terminal policy. History preserves the original grant, adds lease_revoked_at for a grant revoked before expiry, and does not invent natural expiry or physical callback stop. Already elapsed business deadlines keep their own outcome. Both existing deregistration routes use this settlement. Old receipt replay cannot revoke a replacement incarnation. Contention refuses without committing registration/activity state; the actual MySQL NOWAIT code 3572 now maps to typed backend lock pressure.

   Actual component verification:

   • Core regression: 257 tests / 1,825 assertions PASS, one explicit network-only skip on SQLite; PHP 8.3.35 / Laravel 13.38.0 / PHPUnit 12.5.40. Core ECS and focused PHPStan pass.
   • New Server deregistration selection: 10 cases / 98 assertions, two network-only skips on SQLite; 10 / 111, one SQLite fault-injection skip on PostgreSQL 17.11, and the same 10 / 111 with one skip on MySQL 8.0.46. These cover recorded backoff, exhaustion, stale outcomes/receipts, namespace/owner refusal, business-deadline priority, transactional rollback and actual two-connection contention. Final Pint and diff checks pass.
   • Earlier separate renewal/configuration review 9cf82f665 passes 72 cases / 674 assertions against the explicit prepared Core source and 10 / 22 against stock Core 2.8. Those results are separate from this new component.

   Retained failed observations: the first history producer omitted its new optional key from the current payload contract; the retry fixture initially used backoff instead of canonical backoff_seconds; schema-drop fixtures encountered SQLite locking and were replaced with committed, truncated fixtures required for real second-connection checks. Actual MySQL contention initially returned 500 for its unclassified 3572 error. The first PostgreSQL attempt ran before TCP readiness and admitted no scenario; the final ready-server run passes. No deadline, assertion or runtime retry budget is weakened.

   These are source components, not published-package or whole-tree acceptance. Existing draft heads remain distinct: Core #879 at bc03c96d, Server #564 at 386788572. The Server's committed Composer/lock remain unchanged on Core 2.8.0; explicit source overlay acceptance is not dependency adoption. Original hosted failures remain failed. Next: integrate this component with qualified current ancestry, finish automatic PHP/Rust/embedded maintenance, adopt the published Core through the coordinated Server window, qualify the current wire/docs and actual long-activity/killed-worker consumers. #878 remains open.

   Actual cleanup is independently verified at 06:10:14 UTC, before the 06:15 boundary: all phase containers, network, database files/tmpfs, generated dependencies/vendor, caches, logs, source copies, temporary Composer lock and downloaded responses are absent. Both network database servers exited 0 / no OOM. Borrowed images and every foreign resource are preserved. Only clean pushed source and small owning-record buffers remain; no paid host or provider resource was used.

   Source integration and Python merge

   The prepared Core branch now integrates current main 22b2651a at 3b3018a56f0fad5c953a6b02aceb5b626c624cb8 / tree c8175dc77e93f70352781ff89c3bf773462a1b65. The integration adds only the three already-qualified tracing diagnostic test files; production source, resources and Composer are byte-identical to the tested departure component. The prepared Server branch integrates current main b88c175bd1 at d665687495236cfdae6f7b6eb1cf884d2c622e1b / tree a3d60354597718061a9260fda100cdc1682c6842. Reserved native/shared files match that main. These are separate preparation branches, not replacements for the admitted Core/Server PR heads, and need fresh qualification.

   Later source integration: preceding Core bc03c96d finishes every applicable normal check, including its final build, before #879 advances to 3b3018a5. Fresh build 39556756587, quality 39556745148, Sonar 39556756560 and boundaries are independent. The Server preparation then integrates qualified tracing main 74f17aae at 48e0a16ac0530a0dcc58c8f8778e60daaa27823a / tree 10e28c9a7784344d771fcb17b80bc88c30eaaa30. Both tracing fields and outer poll clock survive the ordinary overlap, along with both provider imports and main's existing config contract. Syntax and diff pass. Reserved files and Composer/lock match that main exactly, inheriting published Core 2.9.0 without adopting the new lease API. The Server PR's old admitted Core 2.8.0 head and failed original remain unchanged. No combined runtime result or new published artifact is claimed.

   Python #183 is source-merged at dbace3da09f2d1f0801464100e1b468690c572bc, with the exact tested candidate tree caf6e199ac96f7295c921b63edf33ad8e65ccc8e. Every required candidate gate passes after one unchanged-source/unchanged-limit retry of the timed-out Python 3.10 job and its dependent jobs. Other jobs retain their original timestamps; they were not rerun. The original timeout remains unexplained and failed. The completed remote branch is deleted and absence verified. Fresh-main CI 39554306509 and its other checks are independent and pending. No package version/tag changed, and no released long-activity or complete #878 acceptance follows.
10. rmcdaniel commented on Oct 21, 2026

    

    rmcdaniel

    on Oct 21, 2026

    Last edited by rmcdaniel

    MemberAuthor

    More actions

    Rust SDK renewal transport

    Continuing #878 in the Rust SDK on published 4.1 source 777e1a44197a6bac75f3ca75646b936066316352. The new optional Client::renew_activity_task_lease requires actual worker-authenticated boolean capability discovery and original bounded task/attempt/owner identities. Discovery and renewal share one positive request window of at most five seconds. It sends no user progress and introduces no protocol floor.

    The caller must independently validate the grant and unchanged original identities/deadlines before using it. This source component does not yet schedule automatic worker renewals or prove the published long-activity acceptance. That remains explicit #878 work, alongside PHP and embedded maintenance.

    New real HTTP controls cover worker-only credentials, namespace/protocol, literal zero identities, escaped task paths, malformed/absent/false capability, invalid bounds, shared stalled-request deadline and typed ownership refusal.

    Draft Rust SDK #111 now contains 66ac9e5307c3bc145061e850a9091f033c8a2f2b / tree 91406ece1bea0205544cf209261f678821cc4960. All 603 library tests PASS, including the seven new tests, on the supported Rust 1.86.0 toolchain with locked dependencies. The all-target/all-feature cargo check also passes with no warnings. Normal formatting and diff checks pass. Clippy is absent from the borrowed toolchain, so no Clippy pass is claimed.

    Initial new tests pass six / fail one: delayed discovery returns a generic timed-out transport error instead of the outer deadline's typed timeout. Exact error capture proves it; the source normalizes that timeout and the unchanged assertion then passes. No deadline is extended. Normal fresh hosted checks/Sonar are queued, with no whole-head hosted or published acceptance yet.

    Actual entire tooling/dependency/build/raw cleanup is verified 06:35:05 UTC, ahead of the 07:15 boundary. Idle tooling exits 143 / no OOM, not application shutdown evidence. Borrowed images and foreign resources remain. No version, dependency, shared/native/frozen or Cloud change is made.
11. 20 remaining items

    Load more

12. rmcdaniel commented on Oct 22, 2026

    

    rmcdaniel

    on Oct 22, 2026

    MemberAuthor

    More actions

    Reproduced failure

    During Workflow #878 installed-artifact acceptance, normal crates.io Rust SDK 4.2.0 against published Server 2.11.0 / Core 2.10.1 did not complete a genuine 360-second blocking activity under the default 300-second lease. Runtime discovery explicitly advertised activity_lease_renewal=true.

    Exact image index: sha256:b29157eb2cf844916debbbb3c01b3257672e0dece778a9c6fa539043a3038f02. Source input is Server PR #630 at 49777f152 (later audit-only head 9adc167d9), independently built against the locked normal SDK with Rust 1.90.0. Binary SHA-256: ff6153895a2d5d3935502985e21c1c1a9f28813aeff0e378ed24f7493004e515.

    • Run 01m5gtjngd0xhhyy3q1et5928m, task 01m5gtjpr864tffqpkdk6d3kx5, attempt 01M5GTJQ1JZVRGBMXVQZAJWNES.
    • The callback uses std::thread::sleep(360) inside the ordinary typed async activity adapter, on a two-thread Tokio runtime. It has no authored timeout or application heartbeat.
    • Activity started at 03:30:51.570754 UTC. Its initial lease was 03:35:51.570913; one confirmation moved it to 03:35:52.270004, then no further extension appears in the stored task/attempt.
    • The original 420-second observer timed out with run waiting. At the observation snapshot the activity was still running, one invocation/attempt, four history events and no application-heartbeat event. Its original run/execution deadline remains 03:37:49.996647. No recovery or extension was used to turn it into a pass.
    • The separate Rust callback-owner-loss original under a configured five-second lease passes in 18.93 seconds, with expired then completed attempts, one recorded lease_expired retry and the exact int64/null/Unicode result.
    • PHP SDK 3.2.0 and Python 2.8.0 both pass the long and owner-loss originals on the same exact Server artifact. Their stopped audits preserve original history/deadlines. This does not establish the cause of the Rust failure.

    Earlier fixture originals were separately refused because I supplied two positional values to a one-request typed handler. They remain unsuccessful and are not this reproduction. The unsigned-type attribution was corrected: argument count caused those refusals.

    Acceptance / next action

    General owns this delivery failure and Workflow #878 remains open. First compare a normal cooperative async callback and this blocking callback, inspect actual renewal requests/refusals and the SDK's authority/task lifetime, and establish the responsible component. Published source already spawns a separate Tokio maintenance task, so an unverified claim that maintenance is simply absent or polled only in the callback is incorrect.

    Fix the product boundary needed for the documented independent runtime-lease guarantee, retain claim/deadline/publication fencing and worker-loss bounds, and expose a useful reason when maintenance stops. Add a short adversarial regression plus the real published six-minute consumer. Do not replace the obligation with application heartbeats, a larger lease, a longer observer or a rescued original. Document async/blocking authoring requirements accurately. No native/frozen actor, Cloud, schema or major-release adoption is implied.
13. rmcdaniel commented on Oct 22, 2026

    

    rmcdaniel

    on Oct 22, 2026

    Last edited by rmcdaniel

    MemberAuthor

    More actions

    Final installed-consumer disposition: five controls PASS; the Rust long control FAILS. Workflow #878 remains open through Rust SDK #117 and remaining Waterline lease-history verification. No all-SDK acceptance is claimed.

    Exact published Server 2.11.0 / 36d162736 / tree e5821c4e, index b29157eb, configuration d198219f, PHP 8.3.36 / Core 2.10.1. Source/image/chart publication is independently successful at 39711732965. Consumers use normally installed PHP 3.2.0, Python 2.8.0 (37 verified production RECORD hashes) and Rust 4.2.0 (locked crates.io checksum). Functional Rust source is 49777f152, binary ff6153895a2d5d3935502985e21c1c1a9f28813aeff0e378ed24f7493004e515; later PR #630 changes add only bounded audit/documentation follow-through.

    Consumer / original	Result	Elapsed	Run
    PHP, 360-second callback / default 300-second lease	PASS	376.46 s	01m5gs7mnkcybdq4e6q83cbrrh
    Python, same long control	PASS	370.66 s	01m5gs7prt9ydzgventfe9zc0b
    PHP, killed callback owner / configured 5-second lease	PASS	28.12 s	01m5gsb0z1rxgjywf1mw9cs9gg
    Python, same owner-loss control	PASS	18.24 s	01m5gsg113ve3ha884ndgq4xvs
    Rust, same owner-loss control	PASS	18.93 s	01m5gtjyj26w8sj8wzxajtcmh8
    Rust, 360-second blocking callback / default lease	FAIL	original 420 s exhausted	01m5gtjngd0xhhyy3q1et5928m

    The five passing originals independently retain exact signed-int64/null/Unicode results, original inputs/deadlines and all 20 sampled history-prefix rows. They have five completed activities, eight actual attempts, 18 tasks and 36 history events. The long cases each have one invocation/attempt; each loss case has expired→completed attempts on the same activity, one recorded lease_expired retry under the original two-attempt/zero-backoff policy, and no task repairs or application-progress heartbeat events. The short loss case does not establish default worker-loss latency. PHP's independent helper changes 1→0 after owner kill; Python/Rust owner processes are absent before replacement, and their original attempts expire before the declared retry. The captured expiry-snapshot pair was not separately compared before raw retirement, so no additional fixed-timestamp equality check is claimed. Three intentionally killed-owner registration rows remain, explicitly retained rather than described as zero registrations.

    Both stopped database audits use read-only mounts/SQLite flags and preserve the exact source hashes: long e46f69b36c6fdcde1ea5e8aa4f05b0e59e605ed3099162c2879333ba8a8a9be5, loss 85a769bca95365282b70ae61c40643dbdbf150f5a6585644e482a25bf76c1080. The first audit expectation wrongly treated a retry task as attempt 1; it is corrected to require the actual declared second-attempt ordinal, with source/runtime/data unchanged. The initial failed verifier and four malformed Rust fixture originals remain unsuccessful observations, distinct from #117's correctly shaped running activity.

    Both APIs and the two final Rust Workers exit 0 after explicit SIGTERM. The intentional killed owner exits 137, and no OOM is reported. No exit-code claim is made for earlier detached PHP/Python Worker commands whose exact exit status was not captured.

    Runtime/compiler retirement completed 03:41:19 UTC; all phase data, SDK/dependencies, binaries, raw captures and network plus the task-pulled Server/unused Waterline cache references were actually removed 03:44:54 UTC, before the revised 03:45 boundary. Borrowed tools, the active native owner's Waterline 2.12.0 image/containers and all foreign resources are preserved. Only clean pushed source and a small readable result remain. No paid/Cloud action, native adoption, stopped inspector/retrieval/observation recipe or original-budget extension occurred.
14. rmcdaniel commented on Oct 22, 2026

    

    rmcdaniel

    on Oct 22, 2026

    MemberAuthor

    More actions

    General is finishing #878's remaining real Waterline visibility check independently of the queued Rust 4.2.1 publisher. Published embedded Core 2.10.1 six-minute/worker-loss acceptance is already recorded here and will not be rerun.

    New bounded cohort: published Server 2.11.0 (index b29157eb), normal Python 2.8.0 and Waterline 2.12.2 (index c78c0e68), disposable named SQLite runtime only. Use the existing configured-five-second owner-loss fixture and original thirty-second observer. Inspect the actual retry/attempt reason and identities in Waterline; inspect the late-completion boundary before making any completion claim. This is not native/browser adoption, performance evidence, a stopped recipe retry or a Cloud action.

    Unique task names and data use general878-waterline-20261022t0600. All newly created runtime, browser/dependencies, databases, raw output and task-only images retire by 06:45 UTC. Existing borrowed Server, Python and other owners' images remain protected. No business is admitted before affirmative discovery and normal installed-package verification.
15. rmcdaniel commented on Oct 22, 2026

    

    rmcdaniel

    on Oct 22, 2026

    MemberAuthor

    More actions

    Published SDK acceptance advances; remaining operator/history defects reproduced

    Normal Rust SDK 4.2.1 now passes genuine blocking and cooperative six-minute originals plus the five-second owner-loss original, with the original 420/30-second observers, cold reads, fixed post-death expiry pair and stopped SQL. Full artifact/result receipt is on SDK #117. Earlier published PHP 3.2.0 / Python 2.8.0 and embedded Core 2.10.1 results remain their own evidence.

    Fresh normally installed Python 2.8.0 UI original 01m5h3yvgs4ytjm9hy2kqvwqky completes in 14.5135 seconds after owner loss under the configured five-second lease. It retains two attempts, four tasks/eight events, the same activity/result, zero task repairs or application heartbeat events. Original task/attempt expiry is identical in both post-death reads: 2026-10-22 06:14:54.510928. Actual Waterline 2.12.2 bounded and complete selected-run requests return 200, with zero page errors.

    Two remaining requirements are not fulfilled:

    1. The physical first attempt is expired, and canonical ActivityRetryScheduled records failure_reason=lease_expired. Waterline's Activities section instead displays Add signals #1 / Failed, stop / attempt_closed. Its supplied typed-history activity metadata itself reports status=failed, so this is not merely a CSS label. Expanding the actual retry payload reveals lease_expired, but the ordinary attempt presentation loses the reason. Source review locates the unconditional retry→failed classification in Core ActivityAttemptSnapshots, and the generic closed-attempt reason in RunActivityView. The direct Python run-description response does not include activity details; no direct activity-endpoint comparison is claimed from that read.
    2. A normal Python client submits the original task/attempt/owner's late completion. The real HTTP response is 409 / stale_attempt / recorded=false, with attempt_status=expired and task_status=cancelled. Business fencing works. The captured run/task/attempt/history tables gain no rejection record and remain exactly unchanged. The whole SQLite hash changes elsewhere, so this is not a claim of zero database writes globally. Durable history visibility for the refused outcome still needs implementation/qualification.

    The current task/attempt is never revived and no success receipt is borrowed from the stale call. The failed first UI fault-injection original remains failed and was retired as terminated; the passing original above is fresh. The final short database has two completed runs plus that one terminated fixture, ten tasks/five attempts/23 events/three killed-owner registrations, zero failed jobs; read-only final SHA-256 32239ae9e04e25cb6db2dfa5d8d1a7361702331eeb7da720a0f017140c12eead.

    Next: correct the canonical expired-attempt projection/reason, then add bounded, authenticated and idempotent rejected-outcome history that preserves all business/claim/namespace/retention fences and replay compatibility. No runtime/schema/protocol or native adoption has been made by this investigation. Current Sample App tuple adoption remains separate follow-through. #878 stays open.

    All owned runtime/compiler/dependency/database/raw/browser/new-image resources were actually removed 06:42:45 UTC, before 06:45. Both APIs and the healthy business Workers exit 0/no OOM. Viewer shutdown required 137/no OOM, and remains unqualified as graceful. No paid host, Cloud operation, frozen retuple, stopped inspector/security/native retrieval or rejected recipe was used.
16. rmcdaniel commented on Oct 22, 2026

    

    rmcdaniel

    on Oct 22, 2026

    MemberAuthor

    More actions

    The next #878 source slice corrects the canonical attempt view reproduced in the installed receipt. Existing durable lease-loss metadata must keep an attempt expired and expose the actual recorded lease-loss reason in both typed-history and projection-backed observations. Ordinary activity failures, authored timeouts, historical records without a specific reason, original identities and current claim authority remain distinct. Reads must not repair rows or rewrite history.

    Tests will first fail against current Core 2.10.1, then qualify the focused view correction. This does not implement the separate rejected-outcome audit requirement or qualify a new package/image. No schema, command admission, shared/frozen fixture or native source change is included. Isolated local dependency/test resources retire by 08:00 UTC; no Cloud or paid host is used.
17. rmcdaniel commented on Oct 22, 2026

    

    rmcdaniel

    on Oct 22, 2026

    MemberAuthor

    More actions

    The remaining late-outcome history work now has a proposed bounded audit contract, followed by test-first source11321f75. The goal is one immutable refusal fact per recognized original attempt, with no rejected payload/failure text, lease/receipt authority, business progress or retention resurrection. Authenticated original task/attempt/owner/namespace binding and a transactional authority recheck come before writes or external resolution. Valid committed outcome retries must not become audit noise.

    The first isolated SQLite bridge tests are now admitted. All new dependency/test/raw resources retire by 08:45 UTC. This is separate from #900's completed 07:34:09 cleanup and its live CI. No native/shared/frozen or Server runtime edit is made by this source phase. A new event's published reader/replay behavior and actual HTTP/UI path still require qualification; the contract is not a released capability.
18. rmcdaniel commented on Oct 22, 2026

    

    rmcdaniel

    on Oct 22, 2026

    MemberAuthor

    More actions

    Fresh published-image acceptance preparation for the canonical activity lease-loss view in Core 2.10.2 / Server 2.11.1. No business workflow is admitted until the exact image/source/package and actual lease-renewal discovery are checked.

    Use normal Python SDK 2.8.0 and the committed Server #630 lease consumer, with the unchanged two-attempt policy, configured five-second lease, 420-second business deadlines and original 30-second whole observer. Lose one actual callback owner, verify the original expiry stops moving, recover through the existing instance-scoped repair pass, and require the same activity's exact typed result through a replacement Worker and a separate cold client.

    On actual published Waterline 2.12.2, inspect that same original on desktop/dark and mobile/light. Require the expired first attempt and lease_expired reason in the real supplied metadata and visible presentation, no stale assets/page errors, and a stopped read-only SQL audit preserving original prefixes/deadlines. No route mocking, runtime source override, extra lease extension or rejected-outcome diagnostic is included. Earlier 2.11.0 presentation failures remain failed.

    Uniquely owned local general878view20261022t1115 resources: one Server API/bootstrap, viewer with its own data volume, browser/SDK tool at 2 CPUs / 2 GiB, private network and synthetic SQLite/state. New viewer/browser/Server pulls are owned unless another active user starts borrowing them; pre-existing images are preserved. All task runtimes, installed dependencies, new unused images and raw state retire by 12:30 UTC. No paid host, Cloud action, native/shared/frozen edit or stopped recipe/probe/retrieval is involved.
19. rmcdaniel commented on Oct 22, 2026

    

    rmcdaniel

    on Oct 22, 2026

    MemberAuthor

    More actions

    Fresh published-artifact consumer outcome: FAILED original; resources retired.

    Server 2.11.1 / 5336a98d, Core 2.10.2, normally installed Python SDK 2.8.0. Publisher 39768142737 passed, including immutable image and Helm publication. Runtime package provenance and all 37 SDK production-file hashes were checked.

    The original 30-second lease-recovery observation timed out. The original worker was killed after one actual activity invocation; the replacement exited zero without invoking that activity. The repair response reported zero candidates and zero repairs. The last observed state remained waiting with four history events, one running activity and its original leased task. The cause is unestablished. There is no completed workflow, cold-result or Waterline browser acceptance, and the failed original has not been retried or rescued.

    The finished phase is fully retired: four containers, its network and volume, database, dependencies and three unreferenced downloaded images. Small failure evidence and source inputs are retained. API shutdown exited zero without OOM; viewer shutdown exited 143 without OOM. No native/shared/frozen evidence or other owners' resources changed.

    Next: establish why the original expired lease was not selected before changing product behavior or the fixture. Published image success does not complete this installed-consumer requirement.
20. rmcdaniel commented on Oct 22, 2026

    

    rmcdaniel

    on Oct 22, 2026

    MemberAuthor

    More actions

    General's next PHP-only follow-through adopts published Core 2.11.1 / 30974a3, which has all 17 published verification jobs passing. Scope: Composer/lock, Server 2.11.2 / Helm 0.3.2 generated metadata and affected PHP image/installed consumer acceptance. Base is current main e8907eb39c05d182fd8782510c922307a0697ec7.

    Native, shared fixtures, runner, OpenAPI and frozen actors stay unchanged by this patch. The new image-toolchain trust correction remains Rust's reserved work and must be integrated/qualified before claiming a fixed current Server image. Earlier failed worker-loss acceptance stays failed. The fresh same-budget worker-loss/cold-result/Waterline run follows actual publication; source and package checks alone do not close it. Draft audit #901 is separate.
21. rmcdaniel commented on Oct 24, 2026

    

    rmcdaniel

    on Oct 24, 2026

    MemberAuthor

    More actions

    The existing rejected-outcome draft #901 is being integrated with current qualified main 789f3b6 before its remaining publication controls. The prepared eighteen-case SQLite deadline component 1118d17 remains separate prior evidence; its authored lease/start-to-close/heartbeat/schedule-to-close/run/execution boundaries now need fresh qualification on the combined source and the network databases.

    This phase will exercise terminal-attempt distinctions and actual concurrent duplicate/pruning serialization, preserving one immutable diagnostic, original identities and refusal, no rejected payload access, and unchanged business state. Authenticated Server early refusal and actual published readers/Waterline remain later explicit acceptance gates; no new event is published or adopted by a current image. Earlier failed installed observations remain failed.

    Only isolated source/dependency/test resources are admitted, with retirement by 01:45 UTC on October 24. No production, paid host, frozen actor, native/shared fixture, stopped inspector, native evidence retrieval or retired installed-observation recipe is involved. The old draft head remains intact until this component is qualified.
22. rmcdaniel commented on Oct 24, 2026

    

    rmcdaniel

    on Oct 24, 2026

    MemberAuthor

    More actions

    Current-main audit preparation and reproduced pruning race

    Separate prepared source is 3456aa1a70, whole 90acc6311b51cf27625a559127fec142772c33c0, native-independent PHP runtime tree 676bd3fbd22b061d412a29480617e6e29560fe10. PR #901's admitted head remains 86ea5d67; no old hosted pass transfers to this preparation and no new full matrix was dispatched.

    The new real two-process control found a PostgreSQL lock-order cycle between pruning and a late expired outcome. A normal Composer installation of Core 2.12.0 reproduces SQLSTATE 40P01 at its run lock. Installed source/dist both identify 789f3b6428db91590edfb45fc6da717113a61ee4, and all 645 production files match the release. Both source and normal-package graphs use Laravel 13.38.0 / PHP 8.3.36. This is an embedded Core reproduction, not a Server HTTP, native or Cloud finding.

    The correction gives already lost claims a run-first audit transaction, matching retention, without taking or mutating business rows in reverse order. It rechecks actual authority before appending: a lease renewed before the run lock creates no refusal fact. Exact attempt spelling, original owner and identity binding remain required. Both reclaimed expired attempts and leases expired before maintenance are covered. Cancelled/terminated retained-state controls preserve their refusal reasons and business state.

    A broader SQLite original then passed 97/98 and failed the actual pruning race at delete activity_attempts with database is locked. That original remains failed. The final correction admits SQLite's writer before reading the retention snapshot using the existing bounded storage helper; it does not retry an application callback or change the original thirty-second process budget.

    Final local qualification on this exact component:

    • 29 SQLite audit controls plus 69 cold-replay cases: 98 pass / 2,911 assertions.
    • 29 PostgreSQL 17.11 controls / 342 assertions and 29 MySQL 8.0.46 controls / 344 assertions, zero skips.
    • Actual separate child processes race completion/failure and pruning, retaining one immutable fact or no detail rows after pruning. Committed failure retries, settled attempts, all six preparation deadline kinds, case aliases, owner absence, rollback and lease-renewal fencing remain covered.
    • Focused ECS and PHPStan pass, including the retention correction. These are component checks; full regressions, normal new-head CI/Sonar and authenticated Server acceptance remain required.

    Reader rollout is a concrete remaining product gate. Normally installed Core 2.12.0 refuses a constructed ActivityOutcomeRejected read with ValueError from its enum cast. Do not publish the emitter yet. Next deliver and qualify a non-emitting reader bridge and a deliberate mixed-version rollout before enabling new facts, then complete authenticated early refusal before external resolution, normally installed PHP/Python/Rust readers and actual Waterline presentation. This is maintainer work, not an operator approval blocker. Existing published package/image behavior and frozen actors remain unchanged.

    All task runtimes, four database containers/data, both networks, the owned patched Composer image and 602,773,005 apparent bytes of dependency/copied-source/cache/database state are retired. Final inventory completed 2026-10-24T01:45:08.295118+00:00, eight seconds after the phase's 01:45 target; no business/test budget was extended. Borrowed images and all foreign resources are preserved. Clean pushed product source and bounded original/final diagnostics remain; review their necessity by 03:00 UTC. No native/schema/frozen adoption, release or full #878 acceptance is claimed.
23. rmcdaniel commented on Oct 24, 2026

    

    rmcdaniel

    on Oct 24, 2026

    MemberAuthor

    More actions

    The reader-first product gate now has a separate implementation: PR #919, exact e814c2217cae9f1e57e1115bef95c179e71a64f8 / whole f92a6ffdc853875a1559d3105026ec169f48044b. It recognizes ActivityOutcomeRejected, retains the diagnostic through history pages/exports and renders its original identity/reason. It introduces no runtime producer, result acceptance, lease renewal or business replay step.

    Actual source qualification is 102 tests / 2,826 assertions, zero failures/errors/skips, on PHP 8.3.36 / Laravel 13.38.0: 33 contract/history/replay controls and 69 immutable cold-replay cases. The five golden business histories keep exact cold/exported state and command positions; a rejected completion leaves an unfinished activity unresolved. History paging is SELECT-only and does not change run state or create projections. Focused ECS/PHPStan and structural corpus validation pass. The original enum refusal and local fixture/setup failures remain recorded; these are not normal published-reader results.

    The rollout contract requires a published reader-equipped tuple and rollback artifacts before enabling the separate emitter. Current new-head CI is pending. #918 release order, normal SDK readers, authenticated Server early refusal and actual Waterline remain maintainer work; #878/#901 remain open. No native, frozen, schema or protocol-floor adoption is inferred.

    All local task containers, the owned tool image and 293,933,384 apparent bytes of dependencies/cache/database state were removed at 02:10:15 UTC, before the phase boundary. Clean pushed source and small necessary diagnostics remain.
24. rmcdaniel commented on Oct 24, 2026

    

    rmcdaniel

    on Oct 24, 2026

    MemberAuthor

    More actions

    The non-emitting reader is now prepared on the combined source 41c0f11 / whole bf656efa1a51daca4dbe59a4ae2d7907857db050 in PR #919, inheriting the exact independent #918 storage/security candidate 97b04d70. It prepares Core 2.13.0 after the separately qualified 2.12.1 patch.

    On PHP 8.3.36 / Laravel 13.38.0 the combined tree passes 132 executable checks / 3,050 assertions, with two explicit network-only skips on SQLite and zero errors/failures/warnings/deprecations. Full ECS and src/tests PHPStan pass. All 2,171 tracked source-export files match the commit; all 138 dependency versions/references match the earlier storage component. The initial PHP 8.5 deprecation and inherited optional-Redis warning invocations remain separately recorded; final source/assertions/deadlines were not weakened. Temporary dependencies, tool image and databases are retired.

    Original reader e814c221 passed all applicable hosted checks and its reviewed Sonar gate (zero OPEN/CONFIRMED, 0.0% duplication), but those results do not qualify this combined tree. Fresh build 40058576046, audit 40058576079, Sonar 40058576093 and normal source/boundary checks now qualify the new tree independently.

    No audit emitter or retention-locking change is included. The reproduced Core 2.12.0 pruning/late-outcome deadlock remains a product defect: extract its non-emitting repair separately, preserving current lease/identity and payload-admission fences. It must not require writing the new event. The already prepared emitting variant remains unreleased.

    Publication, reader-equipped application/Server/rollback images, normal SDK readers and real Waterline remain maintainer delivery work. The failed installed worker-loss original remains failed. No native or frozen adoption and no full #878 completion is claimed.
25. rmcdaniel commented on Oct 24, 2026

    

    rmcdaniel

    on Oct 24, 2026

    MemberAuthor

    More actions

    Compatibility detail for the bounded late-outcome audit in #901: the published PHP 2.11.1 cancel-leased-activity and terminate-leased-activity fixtures (including before-claim and pending-timer variants) refuse late completion with HTTP 409 / recorded: false, and their exact event lists end at WorkflowCancelled or WorkflowTerminated. cancellation-contract.mjs asserts that terminal-history boundary.

    Recording ActivityOutcomeRejected on a closed run would append after that terminal event. Before an emitter is enabled, choose explicitly whether closed runs are excluded or that contract changes. A contract change requires qualification of participating readers and rollback artifacts, followed by deliberate re-recording and native adoption by the fixture owner. Existing frozen expectations remain evidence. Lease-renewal and query-authority fixtures do not independently conflict with this proposal. The cooperative cancellation live-task selection defect in #923 remains separate.

    #919 remains a draft reader-first change; #901 remains a draft with no published emitter. This records the unresolved compatibility decision in the owning issue.
26. rmcdaniel

    closed this as completedin #919on Oct 24, 2026