[codex] Use writer-consistent reads after MySQL writes

[alexstandiford]

What changed

This keeps the read-after-write consistency fix entirely inside the MySQL integration.

The behavior is dynamic:

• Normal reads still use the normal query path.
• insert() runs the insert and SELECT LAST_INSERT_ID() inside the same transaction.
• After insert(), update(), or delete(), the strategy marks that a write occurred.
• Subsequent reads through that strategy instance are wrapped in a short transaction so they use the writer-consistent path.

No datastore-layer interface was added. No public API changed.

Why

PHPNomad's datastore create flow inserts a row, resolves its identity, and then reads the model back. On managed MySQL hosts with read/write splitting, a read immediately after a write can hit a stale reader.

This fix keeps normal reads cheap while ensuring reads that happen after a write can see the write.

Production Evidence Behind This Fix

The triggering incident was observed on the WordPress integration, but the failure mode is MySQL-level: a write commits, then PHPNomad immediately reads the created row to hydrate the model.

Darren's live SmartWorkflowGuru database was pulled into a disposable test install with WP Migrate DB Pro on April 28, 2026. The failed WooCommerce/Stripe order showed:

• WooCommerce order 8870 completed at 2026-04-27 16:27:03 UTC.
• Siren conversions 19 and 20 were created at 2026-04-27 16:26:49 and 2026-04-27 16:26:57 UTC with transactionId = NULL.
• Siren transaction rows 29 and 30 existed with matching timestamps, proving the inserts committed.
• Transaction 30 also had a transaction detail row, but neither transaction had a wc_order mapping for order 8870.
• Earlier live logs showed RecordNotFoundException during IdentifiableDatabaseDatastoreHandler->create() immediately after inserts.

That shape is exactly what happens when PHPNomad's insert succeeds but the immediate post-write read path cannot see the row. The MySQL integration has the same insert-then-read datastore contract, so it gets the same writer-consistent treatment.

Cloudways Test Notes

A standard Cloudways test app was loaded with the live DB. It used plain local-socket MySQL, not the customer's Cloudways Autonomous topology:

• $wpdb class: wpdb
• wp-content/db.php: absent
• DB_HOST: local socket (localhost:/run/mysqld/mysqld.sock)

On that standard Cloudways app, the issue did not reproduce:

• 100 direct insert/select cycles outside a transaction: 0 failures.
• 100 direct insert/select cycles inside a transaction: 0 failures.
• 10 replays of the WooCommerce completed-order hook outside a transaction: all succeeded.
• 10 replays inside a transaction: all succeeded.

This confirms the generic Cloudways app is not equivalent to the customer's Autonomous database topology. The production DB artifact still supports the read-after-write consistency fix.

Impact

This should prevent a successful insert from being followed by a stale read that makes PHPNomad behave as if the inserted row does not exist.

The extra transaction work only happens on insert identity resolution and on reads after a write has occurred in the same query strategy instance.

Validation

• /home/alex/projects/phpnomad/db/vendor/bin/phpunit --testdox --bootstrap tests/bootstrap.php tests/Unit/Strategies/QueryStrategyTest.php
• Result: 2 tests, 8 assertions passing

Note

The full mysql-integration test suite is still blocked by pre-existing package bootstrap drift: there is no local vendor/bin/phpunit, and tests/Unit/ValidateCITest.php references the old Phoenix\\Core\\Tests\\TestCase namespace.

[alexstandiford]

Withdrawing this PR after further reproduction work.

We provisioned a Cloudways Autonomous trial app, imported Darren's database/files/plugins/theme, matched PHP 8.2.9, preserved the Cloudways Redis/Object Cache Pro layer, and ran the Stripe/WooCommerce paths again. The original failure did not reproduce:

• Browser Stripe checkout completed and Siren created a populated conversion, transaction, obligation, and wc_order mapping.
• Stripe process-response, immediate webhook, and gateway test API paths all succeeded.
• A low-level web-pod consistency probe returned 0 failures across 500 raw $wpdb insert/read loops without transactions, 500 with transactions, and 200 PHPNomad datastore creates.

Given that evidence, this writer-consistent read change is no longer justified for this incident. Closing rather than merging.