Retry MariaDB snapshot-isolation error 1020 as a deadlock

[thai2301]

Description

MariaDB enables innodb_snapshot_isolation by default since 11.6.2 (MDEV-35124), which is now reachable on the officially supported MariaDB 11.8 (since 2.4.8-p5) and 12.3 (since 2.4.9). Under it, a locking read on a row that a committed concurrent transaction has changed no longer succeeds silently — it fails with error 1020 (Record has changed since last read ...; try restarting transaction) and rolls the whole transaction back. MariaDB's guidance is to restart the transaction, i.e. it is semantically equivalent to a deadlock (1213).

Magento\Framework\DB\Adapter\Pdo\Mysql::$exceptionMap maps 2006 / 2013 / 1205 / 1213 / 1062 / 1146 to typed exceptions but not 1020, so error 1020 surfaced as a generic exception that DeadlockRecoveryExecutor (and other deadlock-aware retry paths, which catch DeadlockException/LockWaitException) would not retry. The result is frequent, avoidable failures during concurrent catalog writes / price reindex under load on supported MariaDB versions.

This maps 1020 to DeadlockException, so it is retried the same way as 1213 wherever deadlock recovery is already applied, instead of requiring operators to work around it with innodb_snapshot_isolation=OFF.

Related Issue

Fixes #41047

Manual testing scenarios

1. On MariaDB >= 11.6.2 (e.g. 11.8) with innodb_snapshot_isolation=ON (the default), run a workload with concurrent catalog writes that trigger a price reindex under load.
2. Before this change: the reindex intermittently aborts with SQLSTATE[HY000]: General error: 1020 Record has changed since last read in table '...', with no retry.
3. After this change: error 1020 is surfaced as a DeadlockException and retried by the existing deadlock-recovery path, so the operation completes without operator intervention.

Questions or comments

The reporter (and MariaDB's own documentation) classify 1020 as "restart the transaction", which matches Magento's deadlock semantics rather than lock-wait; hence the mapping to DeadlockException (same as 1213) rather than LockWaitException.

Contribution checklist

• Pull request has a meaningful description of its purpose
• All existing and new tests pass
• Static tests pass
• Ensured backward compatibility

[m2-assistant]

Hi @thai2301. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[thai2301]

@magento run all tests

[thai2301]

@magento run Functional Tests B2B, Functional Tests CE, Functional Tests EE, WebAPI Tests