Fix deadlocks when concurrent requests write tracked options

[ilicfilip]

Problem

A user reported Deadlock found when trying to get lock errors in their logs, attributed to Option Optimizer.

Every request writes the options it read to wp_option_optimizer_tracked on shutdown, via Database::batch_insert() (INSERT … ON DUPLICATE KEY UPDATE inside a transaction). InnoDB locks rows in VALUES order, which followed each request's option access order. Concurrent requests (front end, admin, REST, cron) therefore locked the same hot rows (siteurl, active_plugins, …) in different orders and deadlocked. MySQL rolled back the victim and that request's counts were lost. The COMMIT sent afterwards also cleared $wpdb->last_error, so the failure was silent in code.

Fix

• ksort( $options, SORT_STRING ) before writing, so all writers lock rows in one order. SORT_STRING because numeric option names become int keys.
• On a failed insert: ROLLBACK (instead of falling through to COMMIT), preserving the error.
• Retry once on a deadlock. The deadlock rolls back the whole transaction, so the retry can't double count.

Covers both callers: the per-request shutdown write and the legacy-data migration.

Verification (local, MySQL 8.0.33)

Load test: 20 parallel processes × 50 batch_insert() calls of 200 shuffled real option names. Deadlocks counted with information_schema.INNODB_METRICS.lock_deadlocks.

	Deadlocks / 1000 writes
Before (develop)	919, 913
After (this PR)	0, 0, 0 (all 200,000 increments landed each run)

• Retry path: forced a real deadlock against a second MySQL session. The plugin's write was the victim, retried and succeeded; each row got exactly +1.
• PHPCS and lint clean. PHPStan unchanged vs develop (all 44 existing errors are in node_modules).

Not tested: MariaDB. A deadlock that the retry recovers from is still logged once by wpdb, but these should now be rare.

🤖 Generated with Claude Code

[github-actions]

Test on Playground
Test this pull request on the Playground
or download the zip