Repository navigation
Description
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
2ecc674396f40d4527ebca4ba92eba0d6248572dpassed 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 matchsha256: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/andcomposer.jsonhave 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.phptests/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
- The continuation holds signal secondary-index range locks acquired by
ContinuedRunMessageHandoff::transferInstanceScoped/PendingSignalCloser. - Signal admission for another run holds history/task range locks during relation hydration.
- 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.
- 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
- Concurrent signal and cancellation can deadlock on MySQL relation range locks #819 / Retry rolled-back MySQL signal and terminal commands #820, released in 2.5.28, allow bounded retries of rolled-back signal and terminal control commands. They do not remove this embedded workflow-task lock cycle.
- Do not orphan accepted signals when a run completes or continues as new #857 / fix: preserve accepted signals across terminal workflow turns #858, released in 2.7.0, added the signal handoff and explicit terminal disposition paths involved here. Their signal integrity guarantees must be preserved.
- TaskWatchdog and workers lock run and task in opposite order: MySQL 1213 deadlocks under queue latency (2.4.5 to 2.5.20) #796 concerns a separate watchdog/worker run-task lock-order problem.
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
rmcdaniel commentedon Nov 5, 2026
Security disposition: CONFIRMED product defect; the earlier self-closure does not invalidate the report.
I independently reproduced the report against exact current
main98bd98688663c005cb048d88f18119c35b6973b1, using only the two regression-test files from candidate23c8fde91318df4327e62008f08c5e268d8c0166. The test ran on official MySQL 8.4.8 image digestsha256: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_recordsinsert with SQLSTATE40001, MySQL error1213(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 UPDATElock 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.
rmcdaniel commentedon Nov 5, 2026
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.
ContinuedRunMessageHandoffandPendingSignalCloserstill perform locking range reads of received signals. The test interleaves actualRunWorkflowTask::handle()andWorkflowStub::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
WorkflowTaskSignalGapLockTeston candidate23c8fde91318df4327e62008f08c5e268d8c0166, 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.
rmcdaniel commentedon Nov 5, 2026
Security execution-boundary clarification for the independent reproduction:
security-workflow1043-*PHP/MySQL containers;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.rmcdaniel commentedon Nov 5, 2026
Workflow's exact source and Quality Cycle sequence for this P1 correction:
Frozen product candidate: contributor
23c8fde91318df4327e62008f08c5e268d8c0166, tree72aa551294f1296e214c9a7952cef61adaec45fa, over current main98bd9868. 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,finallycleanup 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, head31aa05e42501a206bb2ce5d55b2fb7aeaa708201, tree48095330d2997a278c2237be794c2beb991f344c. 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.testbench.cache; exact candidate passes 22 tests / 134 assertions.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:
composer ecsandcomposer stanobligations 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.composer unitrun. Enforce the committed unit-only 60% contract for the localcomposer coverageobligation; the public full gate also requires its separate combined contract.mysqldriver needs an explicitly selected compatibility control; nativemariadband other driver names retain the old path. No untested isolation/backend is declared qualified.The existing full
php.ymldispatch on branchworkflow/1043-signal-gap-lock-qawithsqlite_timer_qualification=falseis 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.
rmcdaniel commentedon Nov 5, 2026
Select one original full Quality Cycle attempt for the combined qualification reference
workflow/1043-signal-gap-lock-qa, exact head31aa05e42501a206bb2ce5d55b2fb7aeaa708201/ tree48095330d2997a278c2237be794c2beb991f344c, using the existingphp.ymlworkflow dispatch withsqlite_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
mysqldriver 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.
rmcdaniel commentedon Nov 5, 2026
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:
workflow_dispatch, created 2026-11-05T11:24:04Z.workflow/1043-signal-gap-lock-qa, exact head31aa05e42501a206bb2ce5d55b2fb7aeaa708201, tree48095330d2997a278c2237be794c2beb991f344c. Current main remains98bd98688663c005cb048d88f18119c35b6973b1.5c3150cc34c5cfd3b4e4471953c26a7dda815ce7, SHA-25689fb10b43ac5938bcf8d6468993f862b8839eeaae9aaf76ad533ef49d6c723a6; unchanged existingphp.yml,sqlite_timer_qualification=false.Workflow owns results and actual Quality Cycle/dependency/skip attribution. No pass is asserted while the run is active. MariaDB through
mysqlremains 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.rmcdaniel commentedon Nov 5, 2026
The original selected hosted run is terminal SUCCESS: 42018654305, attempt 1, exact QA head
31aa05e42501a206bb2ce5d55b2fb7aeaa708201/ tree48095330d2997a278c2237be794c2beb991f344c. 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.composer unitrun. Testdox confirms all six scope/identity cases and all three schema-boundary cases executed successfully.6d95676b838d1d084ec316d3467e94e899e1ecd7fe398b971c0305614f6b8a75. No separate local composer alias invocation is claimed.8652845548609c338b2d31f828a272273e19728a3579d8af37f74900f7516ee6.Coverage-label discrepancy: the summary artifact literally says
branch: main, while itscommitis the exact QA head above and the actual event/ref isworkflow_dispatchonworkflow/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):
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 nativemariadb, 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
7305b8aa35d1cd073056b385e1d0f4a9985912b7584c421d0ff04c2b5818e69bandd4b63899cff592cd6d5a2259ec85d39547598edf2b0792d40c0f87549af30129. 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.
rmcdaniel commentedon Nov 5, 2026
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, tree48095330d2997a278c2237be794c2beb991f344c. Current main is still98bd9868; contributor #1044 is still exact23c8fde91318df4327e62008f08c5e268d8c0166. The four runtime files stay byte-identical. The disposable test overlay only removes the MariaDB-version exclusion inWorkflowTaskSignalGapLockTestwhile retaining themysqldriver guard. All twelve methods, subprocess barriers and assertions remain unchanged. Its test file SHA-256 is6192b358e44c0f0fc3a081ab2d5c8dfdb42bf63dc66c114662cee8c75c1dedc4. A temporary PHPUnit configuration selects that class alone under suite nameunit, avoiding unrelated feature queue/Redis bootstrap. This remains a concurrent feature control, not another full unit suite.d49ee0e6104ca43dc0ac4de4b71cb55e174b76c576903c465fb9958b960c8ec2bb05e1b514a48127fbbb111d820366a0f01c69cdae80de6a24dccd067ecac9dfsha256:ac59d3f9bc01435102ad8fbb59f882d71a0d1f83016aee28818adb5f728deb4a, PHP 8.4.27sha256:a530aeeefd82f4fa5150f391b6c75462140904780338766f6b03acecb1cca3ce, 10.5 seriesc72e7b0f6fd186083e76f0442d38051b3acf2d1ae5b31001132ae1b783d88989d11e1111b58fd022ee50915655865ca5f99e46893562ce5c2e89e7e5f3e14d7b51fb2d0c52937cb69e030c18eaca490e4447b7208a4a02bbe939cb4136c650dcThe 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:
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.
rmcdaniel commentedon Nov 5, 2026
Read-only downstream inventory for the eventual published #1043 patch:
580d0eac; runtime constraint^2.20.3, lock at Workflow2.20.3/4cfa985bc507b62f; Composer constraint and lock both2.15.12/7c80ffccRunWorkflowTask, as distinct from its native runtime and fiber runner. Select a dependency/image adoption only for an affected consumer.f5b6bc8e; exact Workflow2.20.3inrequire-dev, no runtime Workflow requirementf56904e2/852bb3cf; no direct Workflow dependencyThe existing Workflow
release-verification.ymlcovers 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 contributor23c8fdeas 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.
rmcdaniel commentedon Nov 5, 2026
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 headf23b68d):composer.jsonpinsdurable-workflow/workflowto2.20.3only inrequire-dev; runtimerequirehas PHP and Illuminate Support. The package suggests Workflow for embedded observation. There is no tracked root Composer lock to update.standalone/composer.jsoninstalls 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.WorkflowsController::signalInstanceandsignalSelectioncallWorkflow\V2\WorkflowStub::attemptSignalWithArgumentswith 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:
The existing
testSignalTargetsSelectedRunRouteAndAcceptsScalarJsonPayloadandtestShowIncludesContinueAsNewLineageForHistoricalAndCurrentRunsare 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.
47 remaining items
rmcdaniel commentedon Nov 5, 2026
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.
rmcdaniel commentedon Nov 5, 2026
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: ./semverrepresentation 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 SHAc156a98cebbf50894075c3f1f22d88a658553f7a90bd1d64a21922b0b98237ba.Fresh source tuple:
bfbb09ebdb1538950d897f9aa3c0e5d5e9b8bc214f0de2bc46358612a03147e4.c221ccea576322e3a136201568a2c914f823f56af510624df64243910bd818a8.2a98dd9ef901a7cd1428b4e452215f7af27fc45a934c9b30037014cedc766b5d.4676b121d7a6623fbfae5e961ac32ef9ef037fb75fbaca5b388b115e55448abb.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.
rmcdaniel commentedon Nov 5, 2026
Published installed-package MySQL proof PASS. The delegated corrected one-shot comparison completed on immutable Workflow 2.20.4 /
e3664430fd1b795aadaca89c835d5281502a01cewith 22 tests / 221 assertions / zero failures, errors or skips. This is an actual registry-only installed result, not source-tree substitution.continueAsNewfunction resolve beneath the installed package'svendor/durable-workflow/workflow/src/paths. No local Workflow override was used.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 Core33e1fd05…bade; all 2,334 package files, 690 runtime files and eight critical fixtures match the sealed source.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.
ca76e284e9ee922450e1637850fbbe25202f6f17cd6eb6eceb8715cb713e3b6734148bc71163c399ce0f5f8d4d938808f7df1479cc3cf53571a4376f9068b24f6c8f71a6ab768dddf42bdfd15229d33568681cf0302e8972a46589e88be3341449c97016cd5aafb0e889251c70b15b63687092f074381a46773c718aea2055adThe 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.rmcdaniel commentedon Nov 5, 2026
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):
release,release.published,workflow_runorrepository_dispatch.2.*excluding prereleases), which uses setup-php, plus the all-push Public Boundary scan. The existing original 2.20.4 tag verification42047888916/1already 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.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.
rmcdaniel commentedon Nov 5, 2026
Published Workflow 2.20.4 release notes at 2026-11-05 19:03:49 UTC, following General's explicit notes-only selection. Release ID
435605701is public/stable with targete3664430fd1b795aadaca89c835d5281502a01ceand 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, peele3664430fd1b795aadaca89c835d5281502a01ce, published draft=false/prerelease=false state and empty assets. Body SHA-256 is90debf9b4346b75929f9d78865627f78727f2c7403ba0334c6c09c242c0c77ca.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/1from 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.
rmcdaniel commentedon Nov 5, 2026
Sample App source adoption and normal main acceptance are complete through #319: actual main
c49d7948552e954f607708a045cb323a9e279c6d, treec0cdc1f78add3abd66ddd2852afba6ba52f0b7c1. 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.
rmcdaniel commentedon Nov 5, 2026
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.
rmcdaniel commentedon Nov 5, 2026
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/ tree1ac5eaf36fdd19ef83e9e198edf6612effe1dfb4has 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.
rmcdaniel commentedon Nov 5, 2026
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.
rmcdaniel commentedon Nov 5, 2026
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.
rmcdaniel commentedon Nov 5, 2026
Sample App terminal source/protection follow-through
Sample #324 canonical actual-main receipt accepts exact main
2ecc674396f40d4527ebca4ba92eba0d6248572d/ tree6edaa31545f4c0d474f57866ad035342b46d5474: all 15 workflows / 28 checks green on original attempt 1; candidate 17/17 green. The required empty main-onlydevcontainer-publicationEnvironment 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.
rmcdaniel commentedon Nov 5, 2026
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.
rmcdaniel commentedon Nov 5, 2026
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.
rmcdaniel commentedon Nov 5, 2026
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.