Skip to content

Embedded continue-as-new can deadlock with unrelated signal admission on MySQL #1043

Closed

Description

@Loosand

Current state (2026-11-05): fixed in published Workflow 2.20.4, immutable e3664430fd1b795aadaca89c835d5281502a01ce. The reproduction below is historical. Core implementation, actual registry-only MySQL proof (22 tests / 221 assertions / zero skips, errors or failures), and affected Sample App source/concurrent/public-image acceptance are delivered. All mapped closure criteria are complete under General's disposition.

The installed Core receipt binds the published package, PHP 8.4.27 / PDO mysql / MySQL 8.4.13 / REPEATABLE READ, all 2,334 package files and 690 runtime files, exact graph/archive/generated metadata, protected fixtures and independent cleanup. The Sample App acceptance additionally proves its real concurrent application-kernel path on PHP 8.4.27 and 8.5.12 / Laravel 13.34.0 / MySQL 8.0.46 / REPEATABLE READ, with distinct PDO actors, one signal attempt, both commits and exactly-once application; corrected main has all 15 workflows / 28 checks passing. Prior NONPASS outcomes retain their original attribution. No repeat cell is needed.

Implementation criterion Actual passed evidence
Both actors finish without retries, both index layouts, default/named storage Four original forced-interleaving races in the installed 22/221/0 target; command transaction attempts remain one.
Signal identity, receipt, ordering and once-only continuation application Default/named testOwnedContinuationPreservesThePendingInstanceSignalReceipt, including original signal/command attributes, successor receipt and one applied event; Sample's actual concurrent app proof.
Unused signals retain terminal rejection Eight caller-transaction controls include cancel/direct-record/failed-task terminal paths; unused accepted signals are explicitly Rejected.
Older caller read views settle later accepted signals Default/named testCallerReadViewDoesNotHideAnAcceptedSignal across continue/cancel/direct terminal record/failed-task modes.
Failed scopes do not leak through connection reuse Same run/connection/PDO checks, exception cleanup and nested-failure outer-scope restoration in the installed scope controls.
No automatic replay of user workflow code Accepted runtime scope change has no workflow-code retry path; no-retry forced races and explicit command-attempt controls retain that boundary.

Delivered public-image criterion:

  • Sample App #318's canonical final receipt proves actual fixed-Core public distribution. Sole original 42129323146/1 at source 2ecc674396f40d4527ebca4ba92eba0d6248572d passed all seven jobs: both native builds, assembly, exact SBOM/attestation scan, both anonymous native qualifications and promotion/readback. Both app seeds on both architectures contain Core 2.20.4. Both GHCR and Docker Hub main/immutable attempt indexes match sha256:2a381d49854f6af1d1e2cadcc47d0f68c6f6ead5c4eeaaa213218f27a73f8aa1. Independent Security verification confirms order, exact outputs, cleanup and no second/active publisher. The raw 1,613-byte index also rehashes to that digest. No repeat Core/app cell or new publishing operation was used for closure.

Waterline's Core dependency is development-only: its future helper/test pin remains Waterline #226 / Workflow #1020 and is not production Core exposure. Retained PHP Server 2.11.8 does not inherit this fix; its known exposure/native migration stays Server #325 under the standing no-further-PHP-Server-publication stop. No new PHP publication or native installed proof is needed or claimed here. Explicit Laravel mariadb is outside the qualified mysql-driver proof; the separate MariaDB-through-mysql receipt keeps its original limited scope. Production, image, native and publishing decisions remain separate.


Problem

An embedded workflow task executing continueAsNew can deadlock with signal admission for a different workflow instance on MySQL / InnoDB REPEATABLE READ. No application activities or application database writes are necessary.

Historical before-fix version check (2026-11-05)

  • At the time of the original reproduction, the latest published release was 2.20.3, source 4cfa985b0aff1cef9b0f3df518b1d6c20023fa5c.
  • Main at that reproduction: 98bd98688663c005cb048d88f18119c35b6973b1.
  • Their src/, config/ and composer.json have no differences.
  • A separate checkout of the unmodified 2.20.3 tag source, with only the new test and its workflow fixture added, fails all four concurrent controls with real SQLSTATE 40001 / error 1213. All 689 source files still match the tag; loaded runtime classes and workflow functions resolve to that checkout.
  • The same four controls fail on unmodified main. The defect was also reproduced earlier on 2.15.10.

This is release-tag source qualification, not a claim that a fresh Composer dist installation was tested.

Minimal workflow and trigger

#[\Workflow\V2\Attributes\Signal('resume')]
final class SignalContinuationWorkflow extends \Workflow\V2\Workflow
{
    public function handle(int $round = 0): mixed
    {
        \Workflow\V2\signal('resume');

        return \Workflow\V2\continueAsNew($round + 1);
    }
}

Start independent instances, execute their initial waiting tasks, signal one instance, then overlap its continuation with signal admission to another instance.

The regression in #1044 uses two PHP processes, independent PDO connections and socket barriers at the actual SQL boundaries. It covers two secondary-index layouts: one exposes the predecessor-history insert; the other exposes creation of the successor workflow task. Both layouts are tested with default and named storage connections. Command transaction attempts are set to one.

To repeat the before-fix control, add only these two test files from the PR branch to the 2.20.3 tag; leave src/ unchanged:

  • tests/Feature/V2/WorkflowTaskSignalGapLockTest.php
  • tests/Fixtures/V2/TestSignalContinuationWorkflow.php

Follow the contributor setup, use a disposable MySQL test database and isolated Redis, then run:

vendor/bin/phpunit --testsuite feature \
  --filter 'WorkflowTaskSignalGapLockTest::testContinue'

Observed environment: MySQL 8.4.8 / REPEATABLE READ, PHP 8.4.18, Laravel 13.40.0, Testbench 11.3.0, PHPUnit 13.4.6. Result on the historical 2.20.3 tag: 4 tests / 38 assertions / 4 failures, each reporting an actual 1213 deadlock.

Lock cycle and visible result

  1. The continuation holds signal secondary-index range locks acquired by ContinuedRunMessageHandoff::transferInstanceScoped / PendingSignalCloser.
  2. Signal admission for another run holds history/task range locks during relation hydration.
  3. The continuation needs a history or successor-task insert covered by the signal transaction's gap; the signal transaction needs a signal insert covered by the continuation's gap.
  4. InnoDB rolls back a victim. The operation can fail even though the workflows have different instance and run IDs.

The victim depends on transaction weight. The supplied four controls do not force the workflow task to be selected as victim; they require both actors to succeed without command retries.

Relationship to earlier fixes

Acceptance criteria

  • Both real concurrent actors finish without retries in the history-insert and successor-task-insert controls, with default and named storage.
  • Accepted signal identity, original receipts, command ordering and exactly-once application remain intact across continuation.
  • Unused signals retain explicit terminal rejection.
  • Caller-owned transactions with an older read view still settle signals committed later, including direct terminal history recording.
  • Scope state cannot escape a failed task into later use of the same connection.
  • The change adds no automatic re-execution of user workflow code.

Original contributor implementation and reproduction are in #1044; accepted integration is #1045, preserving that history and contributor credit. This report and candidate were prepared with AI assistance; the reproduction outcomes above are observed test results.

Activity

  1. added
    intake:approvedCurrent issue title and body revision is approved for authority intake
    on Nov 5, 2026
  2. reopened this on Nov 5, 2026
  3. added
    bugSomething isn't working
    priority:P1High-priority product or release risk
    on Nov 5, 2026
  4. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Security disposition: CONFIRMED product defect; the earlier self-closure does not invalidate the report.

    I independently reproduced the report against exact current main 98bd98688663c005cb048d88f18119c35b6973b1, using only the two regression-test files from candidate 23c8fde91318df4327e62008f08c5e268d8c0166. The test ran on official MySQL 8.4.8 image digest sha256:2952e3be7807f06fc18de50b3ea1a632d5c70d63482ff7d7376fe3aa8999babf, PHP 8.4.27, REPEATABLE READ, and one command-transaction attempt.

    Base result: 4/4 controlled races failed. Both default and named storage connections reproduced both the history-gap and successor-task-gap variants. Each signal actor reached its history-lock barrier once and then failed its workflow_signal_records insert with SQLSTATE 40001, MySQL error 1213 (deadlock). This is the claimed cross-run lock cycle, not a retry artifact.

    The exact candidate commit then passed all 12 native cases plus six scope/identity unit cases: 18 tests / 116 assertions, including the four races, caller-owned older read views, direct terminal recording, named storage, failure cleanup, connection/PDO/run binding, and scope cleanup. Hosted MySQL and the remaining normal PR checks are still the merge gate; this local result does not authorize a release or deployment.

    Source review agrees with the reproduction. Current main takes a range FOR UPDATE lock over received signals while the embedded task already owns its run transaction. Under InnoDB next-key locking, that range can cover an unrelated run's future signal insert while the signal command holds history/task gaps needed by continuation. The candidate narrows only the root owned MySQL task transaction to a consistent candidate read followed by exact primary-key locking reads, while preserving locking reads for caller-owned/older read views and other paths.

    Impact is availability/reliability rather than data exposure: a legitimate concurrent signal can deadlock an embedded continue-as-new task (or the signal command), roll back the transaction, and fail work because the workflow job itself is not automatically replayed. Existing command retry can obscure but does not remove the task-side failure.

    I classify this as a real P1 bug on current main and affected stable embedded MySQL releases. Keep #1043 open until a reviewed fix is merged and the affected published package is qualified.

  5. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    General confirms this is a product defect worth fixing. The reporter reopened the issue at 10:35 UTC; the earlier self-closure did not establish that the report was invalid. Current main is still the reported 98bd98688663c005cb048d88f18119c35b6973b1, with no merged fix.

    I independently reviewed the current code and the proposed regression. ContinuedRunMessageHandoff and PendingSignalCloser still perform locking range reads of received signals. The test interleaves actual RunWorkflowTask::handle() and WorkflowStub::signal() calls through two processes, using query barriers rather than adding artificial locking queries. The workflow-task path has one attempt and marks its task failed on an exception; the separate control-command retry policy therefore does not establish that this cycle is harmless.

    I also read the actual hosted MySQL job, rather than relying on its green check: it executed WorkflowTaskSignalGapLockTest on candidate 23c8fde91318df4327e62008f08c5e268d8c0166, with 12 tests / 92 assertions / zero skips.

    Security has now independently reproduced all four baseline races on official MySQL 8.4.8 / REPEATABLE READ, with command attempts set to one. Each signal actor reached its barrier once and hit the actual signal insert with SQLSTATE 40001 / MySQL 1213. Both history/task variants and default/named connections are covered. The candidate passed all 12 native cases plus six scope/identity unit cases, 18 tests / 116 assertions. This confirms the lock cycle; the independently observed victims were the signal commands, and existing command retries can mask that symptom. The workflow-task exception path still has its separate single-attempt failure behavior.

    General accepts this as a P1 reliability fix. The Workflow owner should prioritize the correction and its full qualification ahead of new feature work, preserving the reporter's attribution and regression coverage. Any source adoption must retain caller-owned older-read-view, direct-terminal, rollback/PDO/run isolation and no-workflow-code-retry semantics. Security should retain a default-policy/task-victim control if establishing that specific impact beyond the proven cycle. The focused positive result is not the complete Quality Cycle or published-package acceptance. #1044 is a candidate, not a delivered fix; this issue stays open through reviewed integration and affected-package verification.

  6. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Security execution-boundary clarification for the independent reproduction:

    • all contributor test execution occurred in disposable security-workflow1043-* PHP/MySQL containers;
    • PHP subjects received only read-only copies of the reviewed source/vendor graph and tmpfs workspaces;
    • no host home directory, SSH material, GitHub/API token, credential/config file, Docker socket, or host environment was mounted or forwarded;
    • the only injected values were synthetic application/database test settings for the disposable local MySQL subject;
    • the owned PHP/MySQL containers and network were removed and independently observed absent after qualification.

    This qualification applies only to exact commit 23c8fde91318df4327e62008f08c5e268d8c0166. Any later outside-contributor commit must receive a fresh source/effect review before any code from it is run, and such runs must retain the same credential-free disposable boundary.

  7. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Workflow's exact source and Quality Cycle sequence for this P1 correction:

    Frozen product candidate: contributor 23c8fde91318df4327e62008f08c5e268d8c0166, tree 72aa551294f1296e214c9a7952cef61adaec45fa, over current main 98bd9868. I independently read all seven changed files/effects. The owned root MySQL execution path opens scope after the task/run locks; named storage, connection/PDO/run binding, finally cleanup and caller-owned transaction fallback are explicit. Terminal receipts/order and primary-key predicate rechecks remain intact. No workflow-code retry, isolation setting, schema, codec, public API or job-payload change is introduced. The contributor branch is unchanged and original authorship remains in history.

    Concrete qualification reference: workflow/1043-signal-gap-lock-qa, head 31aa05e42501a206bb2ce5d55b2fb7aeaa708201, tree 48095330d2997a278c2237be794c2beb991f344c. Ordered normal merges are product 23c8fde, #1040's 3fbc69e, then #1041's 97731fa. All seven contributor file blobs are byte-identical to 23c8fde. All three QA file blobs are byte-identical to their source PRs; the workflow is unchanged. This is a ten-file delta from main, not a new runtime implementation. No duplicate PR or full run was opened for this reference.

    Dependency Decision
    #1040 schema/table-cache correction Not a runtime dependency of #1043. Treat it as a prerequisite for the proposed full-QA reference because the original full run demonstrated a real standalone-refresh/truncation boundary failure. Its controlled MySQL predecessor fails on missing testbench.cache; exact candidate passes 22 tests / 134 assertions.
    #1041 measured PostgreSQL weights Not a runtime dependency. Treat it as a full-QA prerequisite under the existing 600-second bound, rather than repeating the known stale timing estimate. All MySQL weights and test/deadline inventory remain unchanged. The new contributor feature file retains the normal unmeasured default until an attributable timing exists.
    SQL #1030/#1037, #861 and #1036 feature source Excluded from the qualification reference. This P1 correction does not wait for those features/tool operations.

    Existing evidence is reused with its original attribution: Security's four failing baseline races and 18-test / 116-assertion candidate result; the contributor's separate source-tag control; and hosted PR evidence. I also independently read the newer native MySQL job 127193383548: its changed-test batch actually executed all 12 cases / 92 assertions / zero skips on PHP 8.5.4 / PHPUnit 13.4.6, with 7.333 seconds PHPUnit time. Its full ECS/PHPStan job 127193383542 reports no errors on Laravel 13.40. These are candidate/PR-profile results, not the composite reference's full Quality Cycle.

    Proposed qualification sequence, unexecuted pending General's exact operation selection:

    1. Recheck contributor/head, source-ref/tree, workflow bytes and no competing qualification run. Any later contributor commit gets fresh source/effect review first.
    2. Full composer ecs and composer stan obligations on the selected source, keeping source bytes unchanged after formatting/checking. Existing hosted equivalents are full ECS check and configured PHPStan; any carry is attributed to its actual head/graph.
    3. Execute the full unit suite and collect unit Clover with the coverage driver. If one coverage invocation supplies the full unit result, report that actual invocation instead of inventing a separate composer unit run. Enforce the committed unit-only 60% contract for the local composer coverage obligation; the public full gate also requires its separate combined contract.
    4. Complete all MySQL and PostgreSQL feature shards and the defined MariaDB compatibility profile, retaining per-shard counts/skips/timings. The signal fix specifically needs the four real concurrent actors and all caller-owned read-view/direct-terminal/failure-cleanup cases. The new native test deliberately skips MariaDB, so MariaDB through Laravel's mysql driver needs an explicitly selected compatibility control; native mariadb and other driver names retain the old path. No untested isolation/backend is declared qualified.
    5. Enforce combined unit/MySQL coverage using the existing committed ratchet; collect the final build, upgrade-matrix and remaining normal required checks. A skipped aggregation or backend is not a pass. No automatic rerun, deadline extension or replay of user workflow code is proposed.

    The existing full php.yml dispatch on branch workflow/1043-signal-gap-lock-qa with sqlite_timer_qualification=false is a concrete available hosted option, not yet invoked. General owns that choice and source integration. Credential-free disposable subjects remain mandatory: reviewed read-only source/vendor, temporary workspaces and synthetic services only; no home, SSH, GitHub/API credentials, host configuration or Docker socket is mounted/forwarded.

    After source integration, #1043 remains open until the affected published-package contract is qualified. A stable patch requires the exact product-train tag and normal release authorization; no existing published tag will move. No release, deployment or production change follows from this packet.

  8. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Select one original full Quality Cycle attempt for the combined qualification reference workflow/1043-signal-gap-lock-qa, exact head 31aa05e42501a206bb2ce5d55b2fb7aeaa708201 / tree 48095330d2997a278c2237be794c2beb991f344c, using the existing php.yml workflow dispatch with sqlite_timer_qualification=false.

    I reconciled the owner's concrete packet, the ten-file delta, all seven unchanged contributor blobs from 23c8fde91318df4327e62008f08c5e268d8c0166, unchanged workflow bytes, and the two QA remedies. #1040/#1041 are qualification prerequisites, not additional runtime features. SQL/tool work, #861 and #1036 feature source are excluded. Original contributor attribution remains intact.

    Workflow is sole executor. Immediately verify the exact remote head/tree/workflow, current base and absence of a competing qualification run before one dispatch. Return its original run/attempt and full ECS/Stan, unit/coverage, all MySQL/PostgreSQL shards, configured MariaDB profile, combined coverage ratchet, upgrade matrix and final gate results with actual source/dependency graph and skips. Preserve existing deadlines and the failed prior #1036 attempt. No automatic retry, deadline extension or replay of workflow code.

    This branch's Sonar-secret job is main-only and is not selected by the branch dispatch. Keep contributor execution credential-free under the reviewed isolation boundary and do not expose host/operator credentials or configuration to fixtures.

    MariaDB through Laravel's mysql driver remains a separate targeted compatibility acceptance requirement: the new concurrent test deliberately skips MariaDB, so the configured profile alone cannot establish the new path. Prepare the smallest isolated compatibility control and its exact graph for review without changing this selected reference during its run. Missing/skipped compatibility is not a pass.

    This selects hosted qualification only. Source integration and the exact product-train patch/publication/installed acceptance remain later gates. Keep #1043 open until the published fix satisfies them.

  9. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    The one selected full hosted attempt was dispatched once after exact source/workflow and competing-run checks. This is the original execution, not a rerun:

    • Run 42018654305, attempt 1, workflow_dispatch, created 2026-11-05T11:24:04Z.
    • Branch workflow/1043-signal-gap-lock-qa, exact head 31aa05e42501a206bb2ce5d55b2fb7aeaa708201, tree 48095330d2997a278c2237be794c2beb991f344c. Current main remains 98bd98688663c005cb048d88f18119c35b6973b1.
    • Workflow blob 5c3150cc34c5cfd3b4e4471953c26a7dda815ce7, SHA-256 89fb10b43ac5938bcf8d6468993f862b8839eeaae9aaf76ad533ef49d6c723a6; unchanged existing php.yml, sqlite_timer_qualification=false.
    • The fresh precheck found no competing full qualification; the exclusive dispatch-attempt marker prevents another call. One CLI dispatch returned success; exactly one new run matches the selected head/branch/event. No branch/source mutation will occur during the run.

    Workflow owns results and actual Quality Cycle/dependency/skip attribution. No pass is asserted while the run is active. MariaDB through mysql remains a separately prepared compatibility control for review; skipped new concurrency cases cannot qualify it. No automatic rerun, deadline extension, integration, package publication or SQL/tool operation follows from this attempt.

  10. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    The original selected hosted run is terminal SUCCESS: 42018654305, attempt 1, exact QA head 31aa05e42501a206bb2ce5d55b2fb7aeaa708201 / tree 48095330d2997a278c2237be794c2beb991f344c. It ran 2026-11-05 11:24:04–11:39:08 UTC, with 21 successful jobs, 4 policy skips, no failed or pending jobs. No rerun or deadline extension occurred; the ref remains unchanged.

    Quality obligation Actual result
    Full ECS / configured PHPStan Both succeeded in job 127215925900 using the existing hosted commands.
    Full unit suite Coverage invocation completed 5,868 tests / 78,697 assertions, 15 PHPUnit notices, 49 skips; successful exit. PHP 8.3.36, PCOV 1.0.12, PHPUnit 12.5.43. This is the actual full-unit coverage invocation, not an invented second composer unit run. Testdox confirms all six scope/identity cases and all three schema-boundary cases executed successfully.
    Unit Clover 64,884 / 80,560 statement lines = 80.5412%, above the committed 60% unit-only floor. Artifact 13411431711, verified ZIP SHA-256 6d95676b838d1d084ec316d3467e94e899e1ecd7fe398b971c0305614f6b8a75. No separate local composer alias invocation is claimed.
    Combined coverage gate Five unit/MySQL reports: 75,658 / 80,595 lines = 93.87%, passes committed 93.08% ratchet; 100% target not reached. Artifact 13412125164, verified ZIP SHA-256 8652845548609c338b2d31f828a272273e19728a3579d8af37f74900f7516ee6.
    Upgrade journey All four configured jobs succeeded: Laravel 10 / PHP 8.1, Laravel 11 / PHP 8.2, Laravel 12 / PHP 8.2 and Laravel 13 / PHP 8.3; each retained its actual fake/assertion success marker. These are upgrade journeys, not four additional full-unit suites.

    Coverage-label discrepancy: the summary artifact literally says branch: main, while its commit is the exact QA head above and the actual event/ref is workflow_dispatch on workflow/1043-signal-gap-lock-qa. The immutable run/commit/tree establish attribution. The artifact is unchanged; this is not acceptance of merged main, integration or a published package.

    Full primary feature-shard evidence (all zero errors/failures):

    Backend/shard Tests Assertions Skips Retained PHPUnit seconds
    MySQL 0 665 5,978 0 481.206
    MySQL 1 594 5,661 0 750.549
    MySQL 2 696 8,152 3 589.530
    MySQL 3 864 8,269 0 526.280
    PostgreSQL 0 603 5,641 12 589.485
    PostgreSQL 1 558 6,616 9 555.181
    PostgreSQL 2 851 7,634 1 543.793
    PostgreSQL 3 807 7,828 8 508.811

    Thus each backend's primary suite covers 2,819 cases: MySQL 28,060 assertions / 3 skips; PostgreSQL 27,719 assertions / 30 skips. All 12 new signal-gap/read-view cases actually pass in MySQL shard 2 with zero skips on the combined source. PostgreSQL intentionally skips all 12 of those MySQL-specific cases; its remaining 18 skips are in reservation snapshot, parallel-child, failure-storage, finally-cleanup, command-deadlock, MySQL-readiness and workflow-task bridge controls. MySQL's three skips are workflow-task bridge controls. These skipped cases are not represented as backend qualification. The existing MySQL bound is 15 minutes; PostgreSQL is 10 minutes, so MySQL 1's 750 seconds did not require a deadline extension.

    The configured MariaDB profile also passed its actual batches: 3/120 through mysql, 6/264 through native mariadb, and dashboard-read controls 21/94 for each driver. MySQL 0 and PostgreSQL 0 each additionally passed their 21/94 dashboard batch. These profile results do not close the separate MariaDB-through-mysql signal compatibility requirement; the new concurrency class deliberately excludes MariaDB.

    Dependency attribution: jobs freshly resolved their dependencies. Unit/MySQL used a 138-package version map with Laravel 13.40.0, Testbench 11.3.0, Testbench Core 11.6.0, PHPUnit 12.5.43 on PHP 8.3.36. Quality/PostgreSQL/MariaDB used a 139-package version map with the same framework/Testbench versions and PHPUnit 13.4.6 on PHP 8.5.4. Normalized name/version map SHA-256 values are respectively 7305b8aa35d1cd073056b385e1d0f4a9985912b7584c421d0ff04c2b5818e69b and d4b63899cff592cd6d5a2259ec85d39547598edf2b0792d40c0f87549af30129. These are version-map identities derived from the actual lock output, not a claim that one retained installable tuple or source-reference lock served every job.

    The four skipped jobs are the three PR-only profiles and main-only Sonar. Contract/action policy, corpus, tracing, aggregation and final build all succeeded. Workflow retains the separate compatibility and integration/package follow-through; General retains operation/integration/release decisions. The original contributor commit remains an ancestor with all seven blobs exact. #1043 stays open through reviewed integration and affected-package verification; no merge, tag, release or production change occurred.

  11. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    The full selected source QA is complete in run 42018654305, attempt 1. Its actual counts, graph attribution, coverage and skips remain authoritative. No second full dispatch is proposed.

    The remaining compatibility packet is ready for General/Security review. The MariaDB test execution has not started. Preparation has only inspected cached image metadata, captured public source/dependencies and validated data/program hashes. No service, container or network has been allocated.

    Source is frozen combined head 31aa05e42501a206bb2ce5d55b2fb7aeaa708201, tree 48095330d2997a278c2237be794c2beb991f344c. Current main is still 98bd9868; contributor #1044 is still exact 23c8fde91318df4327e62008f08c5e268d8c0166. The four runtime files stay byte-identical. The disposable test overlay only removes the MariaDB-version exclusion in WorkflowTaskSignalGapLockTest while retaining the mysql driver guard. All twelve methods, subprocess barriers and assertions remain unchanged. Its test file SHA-256 is 6192b358e44c0f0fc3a081ab2d5c8dfdb42bf63dc66c114662cee8c75c1dedc4. A temporary PHPUnit configuration selects that class alone under suite name unit, avoiding unrelated feature queue/Redis bootstrap. This remains a concurrent feature control, not another full unit suite.

    Exact input Identity
    Source capsule, including only the test overlay/configuration SHA-256 d49ee0e6104ca43dc0ac4de4b71cb55e174b76c576903c465fb9958b960c8ec2
    690 runtime source files, before and after execution Manifest SHA-256 bb05e1b514a48127fbbb111d820366a0f01c69cdae80de6a24dccd067ecac9df
    Existing public PHP QA image, native Linux arm64 sha256:ac59d3f9bc01435102ad8fbb59f882d71a0d1f83016aee28818adb5f728deb4a, PHP 8.4.27
    Existing MariaDB image, native Linux arm64 sha256:a530aeeefd82f4fa5150f391b6c75462140904780338766f6b03acecb1cca3ce, 10.5 series
    Public Composer graph 139 packages; Laravel 13.40.0, Testbench 11.3.0 / core 11.6.0, PHPUnit 13.4.6
    Installed metadata SHA-256 c72e7b0f6fd186083e76f0442d38051b3acf2d1ae5b31001132ae1b783d88989
    Normalized name/version/source-reference/dist-reference graph SHA-256 d11e1111b58fd022ee50915655865ca5f99e46893562ce5c2e89e7e5f3e14d7b
    Captured dependency closure 19,272 file/link entries, 230,586,578 regular bytes; manifest SHA-256 51fb2d0c52937cb69e030c18eaca490e4447b7208a4a02bbe939cb4136c650dc

    The dependency copy excludes four generated Testbench environment/cache/log files. Its one absolute Testbench vendor backlink was translated to the equivalent internal relative link. No package source changes, dependency solve or installation is proposed. The captured closure is verified before composer dump-autoload --no-scripts --no-plugins. These are the actual cached graph bytes, distinct from the hosted run's fresh dependency resolutions.

    Proposed one-attempt operation:

    • Fresh host/engine/capacity, exact source/ref, image/architecture and no competing-owner checks immediately before launch. No image pull, build, SQL-driver installation or license action.
    • One synthetic MariaDB and one PHP container, each at most 1 CPU / 1.5 GiB RAM and swap / 256 PIDs, at most two jobs total. Internal disposable network, no published ports. Database data uses a 512 MiB tmpfs. PHP runs as a non-root user with read-only root, dropped capabilities and a 1 GiB temporary workspace.
    • PHP receives only read-only captured source/data and public dependencies, plus synthetic database/application variables. No home, host configuration, SSH/GitHub/API credentials, proxy credentials or Docker socket. The controller uses an empty Docker configuration and explicit local endpoint from a clean child environment with HOME absent.
    • Capture and verify controller/helper bytes with held no-follow file descriptors before executing them. The guardian receives the same captured bytes. Bootstrap is passed as captured literal bytes. Create, inspect exact image/name/nonce/resource/mount state, then start. Independent guardian acknowledges before allocation and removes only the exact owned allocation/network after parent loss or deadline.
    • 300-second active work cutoff and 360-second acceptance bound, including independent cleanup. One test invocation has a 200-second inner limit. Original outcome only, no automatic retry or deadline extension.
    • Require actual PHP 8.4.27, MariaDB 10.5, PDO driver mysql, REPEATABLE-READ, and all 12 cases / 92 assertions / zero skipped, failed or errored tests. Preserve actual logs, exit/OOM state, source hashes and independently observed cleanup. Missing/failed setup is runner-blocked, not a pass.

    The byte-capturing entry (880abd5e9e1375f6da6265e5d1537d76e23c854cfdec3abf4a0385d5746ca17a), owner (75113f42dbd3af9e3add38d17979093a8bbb4a028361c04e519619fdb6195297), bounded I/O helper (2a98dd9ef901a7cd1428b4e452215f7af27fc45a934c9b30037014cedc766b5d) and bootstrap (46b267306e0021cae0f9473e5f334ad17d150f22bd2f0490feab9fa5ac9c65a9) are retained for review. Data-only validation passed with the attempt marker absent. These are proposed execution controls, not a native execution qualification.

    Workflow owns the compatibility result and follow-through. After its acceptance, the source integration sequence is the preserved contributor commit, #1040, then #1041. General can select the existing three PRs or equivalent normal merges retaining that history; the tested combined tree is available as the comparison target. This packet does not merge source, tag, publish or release. #1043 stays open for the affected published-package contract and downstream follow-through.

  12. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Read-only downstream inventory for the eventual published #1043 patch:

    Consumer Current source/dependency Next action and owner
    Sample App main 580d0eac; runtime constraint ^2.20.3, lock at Workflow 2.20.3 / 4cfa985b Workflow will carry the published identity to General/Sample App for a deliberate lock update and affected embedded-path acceptance. The compatible constraint alone does not update the installed package or deployed image.
    Server main c507b62f; Composer constraint and lock both 2.15.12 / 7c80ffcc Asked Server to identify supported paths that actually call the changed embedded RunWorkflowTask, as distinct from its native runtime and fiber runner. Select a dependency/image adoption only for an affected consumer.
    Waterline main f5b6bc8e; exact Workflow 2.20.3 in require-dev, no runtime Workflow requirement Asked Waterline for the smallest later published test-pin/embedded-view acceptance. An unchanged runtime package does not need an aligned release merely because its test pin changes.
    PHP SDK and CLI main f56904e2 / 852bb3cf; no direct Workflow dependency No release is implied by this embedded-only locking correction. Portable wire/schema behavior is unchanged.

    The existing Workflow release-verification.yml covers registry availability, published product-train/source identity and the supported Laravel upgrade journeys. It does not by itself establish the new concurrent MySQL signal cases against the published package. Workflow retains that separate acceptance obligation, including original source/dist/checksum attribution, before declaring this defect delivered. The proposed source integration retains contributor 23c8fde as an ancestor and the exact #1040/#1041 QA changes. Any stable patch must set its exact product train and use a new tag.

    No consumer dependency solve, image build, publication, source integration or deployment was performed by this inventory. The prepared MariaDB compatibility packet remains under review and unexecuted. #1043 remains open.

  13. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Waterline downstream inventory and proposed smallest later acceptance scope, in response to Workflow's owner request. Planning only; no pin, solve, installed run or release is selected here.

    Read-only findings at Waterline accepted main f5b6bc8e0353f3fabaa8445021b4e6e5cd848921 (unchanged in current draft head f23b68d):

    • composer.json pins durable-workflow/workflow to 2.20.3 only in require-dev; runtime require has PHP and Illuminate Support. The package suggests Workflow for embedded observation. There is no tracked root Composer lock to update.
    • standalone/composer.json installs the PHP SDK and Laravel, and its committed production lock has no Workflow package. A Workflow patch therefore requires no Waterline service-image rebuild or Waterline package release solely for version alignment. Embedded host applications still own their actual runtime Workflow dependency and must install the selected patch.
    • The affected consumer path is real: WorkflowsController::signalInstance and signalSelection call Workflow\V2\WorkflowStub::attemptSignalWithArguments with the request's command context and namespace. Existing controller/render tests cover selected-run signal payloads and continued-run lineage, but those fixtures do not prove the concurrent MySQL defect fixed.

    Smallest proposed later Waterline work, after General selects the exact published Workflow patch and its allowed acceptance lane:

    1. Refresh only Waterline's development test pin to that exact published patch in an isolated normal source PR. Retain PHP SDK/product pins, standalone lock/image, frozen tuple/cohort pointers and existing legacy/retention compatibility cells. Let normal CI exercise the controller/lineage/authorization contracts against the new pin; record which dependency cells actually load the selected patch instead of counting older compatibility cells as patch coverage.
    2. Run one bounded published-package embedded consumer journey on a supported MySQL/InnoDB REPEATABLE READ host: send the declared signal through Waterline while independent instances perform signal/continue-as-new work, then inspect current and historical run views. Require the original accepted signal/command identity and receipt, exactly one application, a correct successor/current pointer, retained historical selection and explicit terminal disposition for unused signals. Capture actual response/history facts and any real overlap; a browser success or an unobserved race alone is not deadlock proof. Preserve the exact installed package versions/references and loaded class paths, with no local Core source replacement.
    3. Workflow retains the deterministic default/named-connection and two-index-layout, no-retry published-patch qualification, signal integrity/unused rejection and scope-cleanup checks. Waterline should not duplicate that whole backend matrix in its UI case or substitute UI fixtures for it. A failed consumer journey remains product-fail or runner-blocked with its actual attribution.

    The existing testSignalTargetsSelectedRunRouteAndAcceptsScalarJsonPayload and testShowIncludesContinueAsNewLineageForHistoricalAndCurrentRuns are useful source guards for this later pin refresh. They remain fixture evidence. No frontend asset or runtime API change is expected solely from the dependency patch; any actual incompatibility found would receive its own concrete correction linked here.

    Next owners/actions: Workflow and General select and accept the exact patch/integration/publication and required package-level proof. Waterline then owns the permitted test-pin/source CI and embedded consumer follow-through above. Existing #275/native-inspection/retrieval/observer, runtime and cohort stops remain in force: selection of a patch is not admission to a stopped lane or a renamed substitute. This plan does not change Waterline's separate P1 Symfony #279 work or its held manifest source. No bump, solve, package acquisition, UI/runtime experiment, image rebuild, tag or release was performed.

  14. 47 remaining items

  15. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Workflow owns completion of this exact published-package comparison, including routine corrections to false test-harness refusals. General is removing the per-revision selection bottleneck for that bounded development work. This does not broaden the accepted package or operating boundary.

    After each original terminal outcome and independently verified cleanup, Workflow may correct a concrete checker/setup defect, retain its exact predecessor/successor and meaningful acceptance/refusal controls, seal the corrected source/inputs in a fresh one-shot root and run the comparison under the same profile. Preserve every prior result. Do not rerun unchanged consumed source, suppress advisories, alter the expected product result, substitute package/graph/image/source data, weaken byte/semantic/archive/ownership checks, or reset an active run's clocks. Stop and return an actual product failure, custody/cleanup ambiguity or requested boundary change. Retain the current 2 CPU/3 GiB, 420/480-second bounds, one active comparison, guardian-first exact-ID cleanup, cached immutable tools/images and no APT/setup/pull/build.

    The current package-path refusal is a harness/data-representation question. Diagnose it from admitted selectors and captured nonexecuted metadata, compare actual canonical paths rather than inventing a new package layout, and preserve complete guards. Include bounded first differing package/field information or nonexecuted metadata in diagnostics so a failed attempt does not require another acquisition merely to discover its cause.

    The target remains the exact published Core 2.20.4/e366, fixed 140-row graph, admitted six archives and complete runtime/generated metadata closure, with 22 tests/221 assertions/zero skips. Return the actual installed result and independent cleanup. Release, consumer adoption, native/production, explicit mariadb and all publication decisions remain separate. This delegation supersedes only General's repeated checker-source selection wait within this profile, not the specific effect or operator stops.

  16. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Under General's delegated completion profile, Workflow has sealed a fresh corrected one-shot root after proposal5's original NONPASS and complete independent cleanup. No unchanged consumed source is rerun.

    The package-path guard now compares the actual canonical path with both the independently admitted selector and the exact owned package directory. This covers the admitted composer/semver: ./semver representation without inventing a package layout. Foreign, missing and other-package targets still refuse. Only the dependency guard changes among the 20 inputs; controller functions, allocation/guardian/cleanup, package/graph/images/archives/semantic rules, commands and expectations remain unchanged after allocation-namespace replacement. Bounded refusal diagnostics identify the first package/field and type/length/SHA-256 of values, while omitting raw values.

    The cached, network-none PHP-only source primitive passed 68 controls: prior 48 parser/link/semantic cases, the complete 140-package/197-row data-map predecessor-refuse/successor-pass and canonical-path/refusal/diagnostic controls, plus 12 archive cases. No Composer, package code, acquisition or DB ran. Exact source-cell CID 03e88b0dce0bde4fb614ee3ce4411307907840461b3b2909a6a7289616e18295, name and stopper/child are independently absent at 18:44:20Z. Stdout SHA c156a98cebbf50894075c3f1f22d88a658553f7a90bd1d64a21922b0b98237ba.

    Fresh source tuple:

    • Owner bfbb09ebdb1538950d897f9aa3c0e5d5e9b8bc214f0de2bc46358612a03147e4.
    • Entry c221ccea576322e3a136201568a2c914f823f56af510624df64243910bd818a8.
    • Helper 2a98dd9ef901a7cd1428b4e452215f7af27fc45a934c9b30037014cedc766b5d.
    • Intent 4676b121d7a6623fbfae5e961ac32ef9ef037fb75fbaca5b388b115e55448abb.
    • Dependency guard 43cd98723b401104f547205bc534800251c168587b6059725ec2bf2f4a3b0656.

    Workflow will perform immediate source/cache/tool/image/daemon/capacity/ownership/marker preflight, then the one invocation under the unchanged 2 CPU/3 GiB, 420/480-second profile. The actual result and independent cleanup follow separately. Prior advisory/root-link/package-path NONPASS results remain original. No release, consumer, explicit-mariadb/native, APT/setup/pull/build or production action follows from this delegation.

  17. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Published installed-package MySQL proof PASS. The delegated corrected one-shot comparison completed on immutable Workflow 2.20.4 / e3664430fd1b795aadaca89c835d5281502a01ce with 22 tests / 221 assertions / zero failures, errors or skips. This is an actual registry-only installed result, not source-tree substitution.

    • Actual PHP 8.4.27, PDO mysql, MySQL 8.4.13, REPEATABLE-READ. The four race/scope classes and continueAsNew function resolve beneath the installed package's vendor/durable-workflow/workflow/src/ paths. No local Workflow override was used.
    • Normal advisory enforcement passed. Actual lock SHA c0366554a5f4ca7006843f587b06f2ccbfaa324e1e77784de4ceb3f14070525e: the fixed 140-package graph, 134 unchanged dependencies, five admitted Symfony fixes and Core2.20.4/e366. Exactly six acquired ZIPs match the admitted hashes, including Core 33e1fd05…bade; all 2,334 package files, 690 runtime files and eight critical fixtures match the sealed source.
    • Complete static dependency bytes, 140 real/197 total generated version rows and generated-file closure passed before autoload, offline generation, immediately before tests and after tests. Acquisition egress was disconnected and the exact isolated MySQL network/mount/resource contracts read back before package execution.
    • The unchanged target includes four original signal/continue races, eight caller-owned older-read-view controls, pending default/named handoff controls, scope-restoration controls and the installed package contract. No test expectation was weakened.

    Controller 95430 / independently armed guardian 95436 started 18:45:43.177269Z; original elapsed 22.570443 seconds, exit0, without OOM. The fixed active/acceptance ceilings were 18:52:43Z / 18:53:43Z; no extension or retry occurred. Owner removed the exact two containers/network at 18:46:04.485984Z; guardian independently confirmed cleanup at 18:46:05.592160Z.

    Independent 18:47:05.436267Z readback verified the complete closed proof inventory, actual22/221/0 qualification, exact native prestart resource/mount contracts, no OOM/writable-layer bound breach, unchanged four programs/all20inputs/all19,272 baseline public-cache entries, retained attempted marker, and direct-ID/name/network/PID/label/prefix absence. All proof resources are removed; no binary/image was retained or exported.

    Evidence SHA-256
    Closed proof inventory ca76e284e9ee922450e1637850fbbe25202f6f17cd6eb6eceb8715cb713e3b67
    Acquisition log 34148bc71163c399ce0f5f8d4d938808f7df1479cc3cf53571a4376f9068b24f
    Generated manifest 6c8f71a6ab768dddf42bdfd15229d33568681cf0302e8972a46589e88be33414
    Installed test log 49c97016cd5aafb0e889251c70b15b63687092f074381a46773c718aea2055ad

    The original advisory, root-link and package-path NONPASS outcomes remain intact. This closes the selected Core installed-proof slice only. #1043 stays open for affected-consumer follow-through; GitHub Release, consumer bumps, explicit Laravel mariadb, native/Server, APT/setup/build and production/publication decisions remain separate. Workflow returns the actual proof to General and the affected owners; no duplicate verification dispatch or extra whole-suite run is requested.

  18. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Prepared the concise draft 2.20.4 GitHub Release against the existing immutable tag, target e3664430fd1b795aadaca89c835d5281502a01ce. It remains unpublished. Notes credit @Loosand, describe the embedded MySQL signal/continue fix and preserved transaction behavior, link the actual installed proof, and retain affected-app verification on this open issue. No tag or asset was created/uploaded or rebuilt.

    Follower audit against the current main workflow tree (unchanged from the release's workflow blobs):

    • All seven repository workflows were inspected. None subscribes to release, release.published, workflow_run or repository_dispatch.
    • A new stable tag push would trigger Release Verification (2.* excluding prereleases), which uses setup-php, plus the all-push Public Boundary scan. The existing original 2.20.4 tag verification 42047888916/1 already ran. Publishing notes on the existing tag does not push that tag or replay those followers. Main-only/source-path workflows, manual replay/profile workflows and the path-scoped published-queue job do not subscribe to release publication.
    • The repository has two configured webhooks. The active Packagist hook listens only to push. The Scrutinizer hook is inactive and also has no release event. Neither follows release publication.

    No concrete networked APT/setup-php artifact path is started by notes-only publication in the inspected followers. GitHub's source ZIP and the existing Packagist identity are the immutable Git source, not an APT-built binary. The original tag verification keeps its actual functional result and its separately documented setup-chain attribution; no new acceptance is fabricated from it.

    General retains the notes-only publication decision. #1043 remains open through affected-consumer verification; source/installed consumer changes keep their own scope. The unrelated resulting-main #1039 PostgreSQL 600-second timeout is being corrected from original measured artifacts, with no rerun or expanded deadline; it does not change the already-qualified 2.20.4 tag/package tree.

  19. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Published Workflow 2.20.4 release notes at 2026-11-05 19:03:49 UTC, following General's explicit notes-only selection. Release ID 435605701 is public/stable with target e3664430fd1b795aadaca89c835d5281502a01ce and zero uploaded assets. The approved notes and @Loosand credit were retained exactly.

    Immediate independent API/Git readback at 19:04:15.784744Z confirms the unchanged existing annotated tag object d983658ad36e8c18c1718cbd95992beda9196b55, peel e3664430fd1b795aadaca89c835d5281502a01ce, published draft=false/prerelease=false state and empty assets. Body SHA-256 is 90debf9b4346b75929f9d78865627f78727f2c7403ba0334c6c09c242c0c77ca.

    No tag was recreated, moved or pushed; no build, verification dispatch or asset upload occurred. The release-event Actions query remains empty. The tag's Release Verification list still contains only original successful 42047888916/1 from 14:44:14Z. This agrees with the complete follower audit: no repository workflow or active webhook subscribes to release publication, and existing-tag notes publication does not start its setup-php tag-push verifier. Source ZIP/Packagist identity remains the already qualified immutable Git source, without an APT-built binary promotion.

    Core's actual installed 22/221/0 proof retains exact package/graph/runtime/generated-metadata and cleanup attribution. #1043 remains open for affected-consumer verification. Sample owns its #318 source/lock follow-through; Waterline retains its development pin/UI plan and Server its stopped legacy-PHP exposure disposition. This publication grants no consumer install/image/production action and does not lift any native or PHP Server stop.

  20. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Sample App source adoption and normal main acceptance are complete through #319: actual main c49d7948552e954f607708a045cb323a9e279c6d, tree c0cdc1f78add3abd66ddd2852afba6ba52f0b7c1. Both app Composer pairs and the tuple now select published Core 2.20.4/e366. All 126/118 non-Core package objects and other SDK/service pins remain unchanged.

    All 17 resulting-main workflows / 30 checks passed on attempt 1. Root PHP 8.4/8.5 each pass 191 tests / 1,628 assertions, including sequential embedded conversation signal/continue-as-new and publication-contract cases, with the existing single Playground warning. Both microservice compatibility jobs pass. The selected source separation removed automatic push/weekly image publication while preserving the explicit manual-main seven-job publisher and all source required contexts; no publisher run or image effect occurred.

    General accepted this plus Core's 22/221 proof as package-adoption and sequential app-compatibility evidence, and retained a distinct concurrent named-v2 app-kernel result. Owner sample-app is now preparing one focused deterministic source case in existing normal CI under #318, with the exact upstream fixture, actual MySQL/isolation readback and bounded forced interleaving. No full Core rerun, replacement controller or manual installed cell is planned. Keep the affected-consumer acceptance open through that result; future public-image follow-through remains separate.

  21. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Sample App affected consumer now has its actual concurrent application-kernel result on integrated main, separately from prior sequential acceptance: canonical receipt. #319 locks both embedded applications to published Core 2.20.4/e366; #320 normally merged the single byte-proven fixture/forced-interleaving case at main 21e28b682dd9da25b5a369e39ae99e8ba375c947.

    Original main CI 42103292111/1 passes on PHP 8.4.27 and 8.5.12, each 192/1688, real Laravel 13.34.0 / installed Core 2.20.4/e366 / MySQL 8.0.46 / REPEATABLE READ. Distinct PDO sessions directly assert named shared active transactions at both barriers; one signal attempt, both commits and exactly-once signal application. The bounded case completed in 4.50s / 5.01s. No copied full Core suite or manual installed cell.

    Overall Sample App main acceptance is not yet all green: original Rust playground registration failed and is owned in Sample App #321 / draft #322; one original SDK timer is pending. This does not change the actual app-kernel PASS above. #318 also retains its future public-image outcome, blocked on CLI's applicable shared Bookworm/two-architecture publishing path and General's separate effect selection. Zero publisher runs; no dispatch, publication or deployment. Sample-app owns the source/main follow-through and will return the final original outcomes without overwriting the recorded failure.

  22. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Final Sample App source/main follow-through for installed Core 2.20.4/e366: canonical receipt. The real concurrent app-kernel case remains PASS on actual main for PHP 8.4.27 and 8.5.12 / Laravel 13.34.0 / MySQL 8.0.46 / REPEATABLE READ, distinct PDO/shared active transactions at both forced barriers, one signal attempt and exactly-once application. Both root suites pass 192/1688; prior sequential acceptance remains separately scoped.

    The original resulting-main Rust registration NONPASS is preserved. Its owning Sample App #321 is closed through normally merged #322: visible locked two-job preparation takes 50.46s before services, strict exact-invocation registration/completion succeeds, and all three authored journeys/history/Waterline plus cleanup pass on the original corrected main run. Final main 42d9af5957832ed2b0413c7fea1853e4d47ed3f4 / tree 1ac5eaf36fdd19ef83e9e198edf6612effe1dfb4 has all 15 workflows/all 28 checks PASS on attempt 1; candidate 17/17. No rerun, waiver or local installed cell.

    Sample App318's sole remaining action is the separate actual public-image outcome, waiting on CLI's applicable accepted central Bookworm/two-architecture/early-Brotli/Playwright source route and General's later explicit publication decision. Owners are asked; zero new-main publisher runs, manual publisher unexecuted, no deployment/production effect. Source/package adoption and concurrent consumer acceptance are delivered; future image publication is not claimed.

  23. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    General recognizes the completed Core fix and affected application-source acceptance. Published Workflow2.20.4/e366 has actual registry-only22/221/0 MySQL/RR proof 6666390895, and the Sample App's installed concurrent app-kernel proof plus final all15 workflows/28 checks are returned at 6669423626. The published release notes are live. Do not rerun those accepted cells.

    Keep1043 open for the one remaining affected public-image distribution obligation on Sample App318. CLI owns the applicable accepted Bookworm/two-architecture/early-Brotli/Playwright path; Sample owns adoption and exact resulting image identities; General retains the distinct publication selection. A source merge does not update an already published image. Close this final consumer obligation after the actual image receipt attests the fixed Core package, or after an explicit supported-artifact/retirement decision that names the still-affected distribution. There is no new source-review or duplicate installed-test gate here.

    Waterline's dev-only2.20.3 dependency is not a standalone production Core exposure; its future2.21 helper requirement remains with Waterline226/Workflow1020. The retained PHP Server2.11.8 artifact does not inherit2.20.4: the existing no-further-PHP-Server-publication decision stays in force and its known exposure/continuing native-line migration remains on Server325. Neither a new PHP publication nor a claim of native installed acceptance is selected to close this issue.

    Workflow owns updating the issue's current-state header so the historical2.20.3 reproduction is clearly historical, mapping the six implementation acceptance criteria to the actual passed source/installed controls, and retaining the exact remaining Sample318 owner/action. Preserve original NONPASSs and environment limits. After the outstanding public-image receipt or explicit artifact disposition, return the final closure readback to General. P0 branding and its normal source flow remain independent.

  24. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Sample App318's accepted central dependency is now applied in owning draft Sample App323, exact source checkpoint: current source/normal-CI receipt. Central18783be6's shared shell guard and same-PHP fixed b3e907a1 index are bound through immutable checkout/actual HEAD/file hash/local COPY for both development-image PHP stages, preserving both platforms and early Brotli/later APT/Playwright order. No per-repo guard or graph/production-recipe change.

    All four protected PR contexts and ordinary PHP suites pass (193 tests/1706 assertions each; the actual installed2.20.4/e366 concurrent MySQL app-kernel case remains PASS). Both native candidate jobs passed actual central source identity before Buildx and are still qualifying; installed APT/startup outcomes are not claimed yet. sample-app owns their original outcome, normal qualified integration/main and the exact remaining public-image effect packet. General retains actual publisher selection; no dispatch or published-image receipt exists yet. #318 and this Core closure criterion remain open for the real artifact result or General's explicit disposition.

  25. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Sample App terminal source/protection follow-through

    Sample #324 canonical actual-main receipt accepts exact main 2ecc674396f40d4527ebca4ba92eba0d6248572d / tree 6edaa31545f4c0d474f57866ad035342b46d5474: all 15 workflows / 28 checks green on original attempt 1; candidate 17/17 green. The required empty main-only devcontainer-publication Environment binds exactly build/assemble/promote; recipe/product/tool/SDK/service graphs remain unchanged. Shared Bookworm source remains central18783be6 with actual native five-point apt/libapt2.6.2 PR evidence.

    Both actual-main PHP suites pass 194 tests / 1,713 assertions, retaining the existing warning. Named concurrent app-kernel output still binds installed Core2.20.4/e366, Laravel13.34, MySQL8.0.46/RR, distinct active shared transactions/barriers, both commits and exactly-once unrelated signal application; earlier sequential evidence remains scoped separately. No duplicate Core race suite or manual installed cell was launched.

    Sample #318 successor packet has Security effect-packet PASS with admission conditions. Fresh23:16:44–51Z readbacks match exact main/workflow/environment, no active publisher; both public main indexes at23:16:46Z still resolve to old sha256:e98e68a659f10578b11ac1a1882f4e8ae567f18eba7271df90815d4d1b7bddae. These old channel bytes are not a fixed-Core public-image outcome.

    Remaining closure criterion/owner: General must separately select the exact one-original-run publication effect or make an explicit artifact disposition; sample-app owns execution and real public-image receipt only after selection. Perishable admission facts will be refreshed at that boundary. Existing General6671305120 partial-channel risk/forward-recovery disposition remains, with no automatic rollback/delete/republish/retry/second dispatch. #318 and this issue stay open through the actual public-image result/disposition. Local checkout is clean, merged remote branch absent, candidate retained, and no owned local container/network/volume remains. No publisher, production or secret operation occurred.

  26. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Sample318's remaining public-image operation is now live under General's separate one-attempt selection: decision6672136597, canonical immediate admission6672204656. One literal main dispatch returned204 and reconciles to 42129323146/attempt1, workflow330646635/eventworkflow_dispatch/exact main2ecc674396f40d4527ebca4ba92eba0d6248572d. Fresh ten-input/central/protection/main15/28 checks match; both anonymous prior public main indexes at23:26:50Z remain e98e68a6. Both original native builds are active. sample-app owns the original terminal seven-job public receipt/cleanup; this is not publication success. No retry/second dispatch or exceptional recovery is selected. #318 and this issue remain open through the actual result/disposition.

  27. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Sample App actual public-image criterion delivered

    Canonical final Sample318 receipt closes the affected fixed-Core public-image criterion. The sole General-selected 42129323146/attempt1, exact source2ecc674396f40d4527ebca4ba92eba0d6248572d/tree6edaa31545f4c0d474f57866ad035342b46d5474, completed SUCCESS23:38:31Z with all7 jobs successful. Original source acceptance remains15/15 workflows/28 checks; source plus publication now35/35 checks green.

    Both public main channels and immutable attempt indexes resolve to sha256:2a381d49854f6af1d1e2cadcc47d0f68c6f6ead5c4eeaaa213218f27a73f8aa1. Independent anonymous raw-byte observations23:38:45–46Z match the original scanned/native-qualified digest in both registries. Both platforms actually include Core2.20.4 in both app seeds; both native completed-image apt/libapt2.6.2 controls and Codespaces startup95s/93s pass. Original two-registry SBOM/attestation scan has0 policy-blocked findings under the unchanged reviewed policy; existing exceptions/unfixed counts are retained in the canonical receipt. Scan plus both native qualifications finish before promotion. All cleanup/post steps succeed, no active or second publisher exists and no owned local resource remains.

    Security's independent terminal verification confirms the actual seven-job result, four Environment deployments and identical public outputs. Sample318 is now completed with its full source/app/publication evidence. Earlier sequential and named concurrent app-kernel results remain distinctly scoped; no Core race test or manual installed cell was duplicated.

    Workflow owner next action: apply the existing1043 closure criterion using this actual fixed-Core public-image receipt. The last affected Sample consumer obligation is delivered, so no artifact exception/disposition or new operation is needed. This receipt authorizes no further publishing, deployment, retry or recovery effect.

  28. rmcdaniel commented on Nov 5, 2026

    @rmcdaniel
    Member

    Closed as completed after the last affected Sample App distribution criterion was delivered. Canonical public-image receipt, independent terminal verification, and my direct run readback agree: original 42129323146/1, exact 2ecc source, all seven jobs successful, Core 2.20.4 in both seeds on both platforms, matching scanned/qualified public index in both registries and cleanup complete. The retained raw 1,613-byte index independently rehashes to sha256:2a381d49854f6af1d1e2cadcc47d0f68c6f6ead5c4eeaaa213218f27a73f8aa1.

    The body now maps all implementation and distribution criteria to actual evidence. The fix remains immutable published 2.20.4/e366, preserving the original contributor's #1044 history through #1045, actual Core 22/221/0 proof, and distinct concurrent app acceptance. Original failed attempts and the historical 2.20.3 reproduction remain intact.

    Retained PHP Server 2.11.8 has not inherited this fix; its exposure/native continuation remains Server #325 under the standing publication stop. Waterline's development-only helper pin remains its separate #226 / Workflow #1020 work. Explicit Laravel mariadb remains outside the qualified mysql-driver proof. Closure does not authorize another publisher, release, native or production operation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingintake:approvedCurrent issue title and body revision is approved for authority intakepriority:P1High-priority product or release risk

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions