Skip to content

Keep engine transactions on the workflow storage connection - #964

Merged
rmcdaniel merged 3 commits into
mainfrom
fix/893-storage-transactions
Oct 31, 2026
Merged

rmcdaniel merged 3 commits into
mainfrom
fix/893-storage-transactions

Conversation

@rmcdaniel

@rmcdaniel rmcdaniel commented Oct 31, 2026 •

Copy link
Copy Markdown
Member

When workflow storage differs from the application connection, engine transactions can open on the application connection while durable rows are written elsewhere. Failed starts retain partial state, task claims release their row locks immediately, and lifecycle events can escape an outer rollback.

Resolve the engine connection from DW_STORAGE_CONNECTION or the configured V2 run model. Transactions, transaction-level checks and callbacks use that connection; task dispatch uses the actual task connection, and lifecycle events use the actual run connection. Preserve existing SQLite retry limits, legacy storage separation, execution tracing and the service-model connection mismatch refusal. Set the patch release identity to 2.15.9.

Validation:

  • Exact original main 45cbdb40 fails the same five rollback, claim, dispatch and lifecycle cases on PostgreSQL 17 and MySQL 8. The original also fails the independent row-lock probe.
  • Fixed configuration and custom-model modes pass 43 tests / 210 assertions on PostgreSQL and 12 / 76 on MySQL. Two real competing-claim tests per driver prove the physical row lock remains held and only one claimant obtains a lease.
  • Activity tracing: 48 tests / 1,175 assertions; schedule tracing: 14 / 1,134. Rollback fixtures inject their failure during the write, retaining all rollback assertions.
  • Official replay-corpus counterfactual validation passes: 82 to 83 replay fixtures, one verified new fixture. Original consumer passes without the new fixture and fails with it.
  • Full unit cycle passes: 5,268 tests / 74,647 assertions, 45 skips and 15 PHPUnit notices; no errors or failures. Coverage and PostgreSQL feature qualification are running.
  • Normal hosted CI is terminal success on 5ac7ff40: 17 successful checks and seven skipped. Full style and static analysis pass. Sonar passes; the specific acceptance of 25 unchanged closure findings is documented in the review.
  • Companion connection documentation is in docs #416, with all eight locales built successfully.

Delivered in Core 2.15.9 together with #965, which completes interleaved callback ownership and real queue publication. All main/published checks and the five-command local quality cycle pass. Stock Composer acceptance verifies 22 storage cases per PostgreSQL/MySQL driver and all 1,007 runtime files. Docs #416 is deployed in all eight locales.

Refs #893.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Reviewed all 26 maintainability findings reported for d95fbd27.

The new connection resolver's return-count finding is being fixed in source and remains unaccepted.

The other 25 findings (php:S1142 and php:S138) describe pre-existing large transaction callbacks. A PHP-token comparison against base 45cbdb40 verifies all 25 callback bodies and signatures match after removing whitespace/comments and normalizing only the changed transaction/after-commit receiver. Their return counts and control flow are unchanged. This is a specific acceptance of existing maintainability debt for the storage-correctness fix; refactoring those handlers would add unrelated behavior risk. No quality profile, gate, security rule or annotation setting is changed.

Each accepted finding receives this decision and its individual comparison digest in Sonar. The normal analysis must still pass on the final head, including the resolver correction. This does not waive behavior, concurrency, coverage or release qualification.

@sonarqubecloud

Copy link
Copy Markdown

@rmcdaniel

Copy link
Copy Markdown
Member Author

A control using the currently published 2.15.8 package reproduces another consequence of the connection mismatch. Composer installs source reference 45cbdb408fd3bcd14e08fac5e8e1375870c20aa5; six relevant product classes resolve from the installed package.

With PostgreSQL workflow storage and an independent SQLite application transaction, rolling back the application removes its own row while retaining the committed workflow run and task. The engine makes zero queue push calls, both before and after the application rollback, although the start event has fired. This uses QueueFake to observe the engine's enqueue boundary, not physical broker persistence. The standalone control terminates with the intended failure.

After publication, the same probe must pass with 2.15.9 in both configured-storage and custom-model modes. A separate Composer project already requires exactly 2.15.9 and will verify the installed source reference and class origins before acceptance.

Normal hosted CI is terminal success on 5ac7ff40 (17 successful checks, seven skipped). Full local unit qualification passes 5,268 tests / 74,647 assertions, with 45 skips and 15 PHPUnit notices. Local coverage and PostgreSQL feature qualification remain in progress; no fixed package has been published yet.

@rmcdaniel
rmcdaniel marked this pull request as ready for review October 31, 2026 01:34
@rmcdaniel
rmcdaniel merged commit bf1f214 into main Oct 31, 2026
24 checks passed
@rmcdaniel
rmcdaniel deleted the fix/893-storage-transactions branch October 31, 2026 03:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant