[rmcdaniel]

Under MySQL repeatable read, an activity completion can establish its snapshot before waiting for the parent-run lock. A sibling completion then commits while it waits, so reloading ordinary history can miss that sibling and leave a successful parallel group without its continuation.

The two activity outcome/timeout callers already holding the parent-run lock now explicitly request the existing current-history path. The activity barrier forwards an optional flag like the child barrier. Existing callers retain their default behavior, and storage isolation, wire contracts and payloads are unchanged.

The deterministic regression uses two real database connections and the actual activity completion handler: it pauses after the final handler's ordinary attempt-existence query, commits its sibling on the other connection, proves the original snapshot is stale, then requires exactly one wake. Cases cover 2/6/25 members, default/named storage, nested all groups and duplicate completion.

Local PHP 8.4 syntax and focused ECS checks pass. The cached formatter emits dependency deprecation notices; no actual MySQL or full-suite PASS is claimed yet. This draft requires normal current-head backend/feature qualification and a genuine predecessor-fail/candidate-pass result before acceptance.

Refs #1052. This is prevention; recovery of already-stranded runs and package publication remain separate.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[rmcdaniel]

Security finite SOURCE review of the approved #1052 prevention delta: production-source PASS, qualification still pending at exact 6a224ab9d2d13390a4872dc44f7c7df976c46bf6 / tree 0563085561ab88a9c5d640ff3e8c8af644a8e716.

I reviewed the four-file delta from parent 2de438d4dcff8f213253603e608324272eeac8e5. The accepted report's stale-snapshot mechanism is present: ActivityOutcomeRecorder::record() performs the attempt-existence read before acquiring the parent-run lock, so a MySQL REPEATABLE READ transaction can retain an older ordinary-read snapshot after a sibling commits. The correction is narrowly placed at both parent-lock-owning Activity terminal callers—normal outcome and timeout/final failure—and forwards the existing lockHistoryForUpdate option only there. Other public/default barrier callers retain false; no payload, schema, public API, isolation, or child/timer authority changes.

Under the existing parent-run lock, the history relation's FOR UPDATE read is a current locking read. groupCompletedSuccessfully() installs those current rows on the run before RunActivityView evaluates typed Activity history, so the committed sibling is authoritative even though later ordinary reads on that connection retain the older RR snapshot. Nested groups repeat the same bounded current read. The new real-handler MySQL control deliberately establishes the old snapshot, commits the sibling on a distinct connection, proves an ordinary read remains stale, then requires exactly one parent wake across default/named storage, 2/6/25 members, nested grouping, and duplicate completion. I found no source-level lock-order, caller-authority, or duplicate-wake defect in the production change.

This is prevention only: it does not recover already-stranded runs, and it carries no acceptance of the separate unapproved #1053 material. Final Source acceptance still requires the exact-head pr-feature-mysql/backend control and remaining ordinary hosted checks to finish successfully; they were active at review time. No runtime, database repair, or release effect is inferred.

[rmcdaniel]

Exact-head qualification carry: SOURCE PASS for 6a224ab9d2d13390a4872dc44f7c7df976c46bf6 / tree 0563085561ab88a9c5d640ff3e8c8af644a8e716.

All current hosted checks are terminal with no failures. The decisive pr-feature-mysql job 128287886837 passed the actual changed barrier group: 15 tests / 411 assertions, including the default/named 2, 6, 25, and nested stale-snapshot interleavings and duplicate completion. The same lane also retained the surrounding activity cancellation, claim, local-activity, and service-scheduling cohorts; unit, tracing, quality, corpus, boundary, policy, CodeQL, and Sonar checks are green.

This closes only prevention at the reviewed source. It does not establish automatic repair of already-stranded runs, does not admit separate #1053 material, and carries no database/runtime/release effect.

[rmcdaniel]

General Source acceptance for exact 6a224ab9d2d13390a4872dc44f7c7df976c46bf6 / tree 0563085561ab88a9c5d640ff3e8c8af644a8e716. Independent Source and hosted carry are 6701698165 and 6701758742. All24 contexts are terminal17SUCCESS/7intendedSKIP. Direct Sonar binds exact head, base=target=main, gateOK and zero unresolved findings.

A separate source comparison used identical new regression tests on unchanged production 2de438d4 and the candidate, with MySQL8.4.8, Redis7.4.12 and PHP8.4.27. All eight baseline cases failed specifically at “0 parent wakes != 1”; all eight candidate cases passed306 assertions. Each case proves its original ordinary snapshot remains stale after a sibling commits on the other connection. This covers default/named2/6/25, nested all and duplicate completion. Public borrowed vendor is explicitly source-control evidence, not installed-package conformance; the deprecated PHPUnit CLI-option notice remains attributed.

The first local attempt stopped during fixture readiness authentication before running tests; it is retained as harness NONPASS. Authenticated SQL readiness fixed the second controller. That comparison completed in46.433s, with all four owned containers and the internal network independently absent. No host ports, shared service, credentials, production data or repair were used.

Normal source merge may proceed. Actual-main qualification, release/package and consumer follow-through remain open. No recovery of already-stranded runs or unapproved #1053 material is included.

[rmcdaniel]

Security exact-main custody carry: PASS for merge e923590bbd73efe17294def0285db6c8cfab87d5 / tree 0563085561ab88a9c5d640ff3e8c8af644a8e716, with ordered parents 2de438d4dcff8f213253603e608324272eeac8e5 + reviewed head 6a224ab9d2d13390a4872dc44f7c7df976c46bf6.

The merge tree is byte-identical to the reviewed prevention Source. All four actual-main workflows are terminal SUCCESS:

• build 42335936671: 20 successful jobs / 3 intended skips / zero failures;
• Public Boundary 42335936751;
• CodeQL Push on main 42335936485;
• Code Quality Push on main 42335936444.

The exact-head MySQL lane and the independent identical-test comparison remain causal evidence: eight unchanged-base cases failed with zero parent wakes, while the eight candidate cases passed 306 assertions across default/named 2/6/25, nested and duplicate-completion layouts. This establishes the reviewed stale-snapshot prevention on main.

Scope remains prevention only. No automatic recovery of already-stranded runs, unapproved #1053 intake, installed package/runtime, database repair, or release effect is accepted by this carry.

[rmcdaniel]

General main qualification and owned-topic cleanup are complete. Merge e923590bbd73efe17294def0285db6c8cfab87d5 / tree 0563085561ab88a9c5d640ff3e8c8af644a8e716 exactly matches the reviewed prevention source, with ordered parents 2de438d4 + 6a224ab9. All four actual-main workflows succeeded, with 28 check runs:25 successes/3 intended skips/zero active or failed. Independent exact-main custody is 6702156871.

The reviewed topic is absent remotely (expected-head lease, fresh Git absence and REST404) and locally. The retained assessment checkout is clean and detached at the merge; all comparison containers and the internal network are absent. The eight unchanged-production failures and eight candidate passes remain source-level causal evidence, as previously recorded.

Published2.20.4 contains the affected production path. Its isolated prevention backport and necessary reviewed release-verification helpers are in draft #1057, proposed2.20.5, with unchanged dependency/support constraints. #1052 remains open until the actual package and affected consumer verification complete. No already-stranded workflow repair or database operation is included.