@@TX_ISOLATION query fails silently on MySQL 8.0+

[zhyian]

Bug Report

When visiting the Matomo system report page (wp-admin/admin.php?page=matomo-systemreport) on a WordPress site running MySQL 8.0+, the following error is logged:

Unknown system variable 'TX_ISOLATION'

The error originates from WpMatomo/Db/WordPress.php at line 440, where wpdb::get_var() executes:

SELECT @@TX_ISOLATION

The @@TX_ISOLATION system variable was deprecated in MySQL 5.7.20 and removed in MySQL 8.0. The correct variable since MySQL 5.7.20 is @@transaction_isolation.

Root Cause

The WordPress DB adapter's fetchOne() uses wpdb::get_var() internally, which does not throw on query failure — it logs the error silently and returns null, which is then converted to false:

// WpMatomo/Db/WordPress.php:440
public function fetchOne($sql, $bind = array()) {
    global $wpdb;
    $prepare = $this->prepareWp($sql, $bind);

    $this->before_execute_query($wpdb, $sql);
    $value = $wpdb->get_var($prepare); // fails silently on MySQL 8.0+, logs error
    $this->after_execute_query($wpdb, $sql);

    if ($value === null) {
        return false; // no exception thrown
    }

    return $value;
}

Any caller that queries @@TX_ISOLATION and relies on an exception-based fallback to @@transaction_isolation will never reach that fallback when going through this adapter — the error is swallowed by wpdb and false is returned instead.

Environment

Plugin	Matomo Analytics 5.7.1
WordPress	5.9.1 Multisite
PHP	8.4.18
MySQL	8.4.7
Hosting	WP Engine
Affected page	wp-admin/admin.php?page=matomo-systemreport

[diosmosis]

TX_ISOLATION queries should have errors suppressed via classes/WpMatomo/Db/WordPress.php. Can you get a full stack trace for the error?

[zhyian]

I unfortunately cannot provide a PHP stack trace from our current logging setup (Wonolog → Logz.io only captures wpdb->last_error and the last query).

[zhyian]

We have another log entry from a wp-cron run (wp-cron.php) that shows wpdb->last_error accumulating 44 errors in a single request. Both query types that should be suppressed according to before_execute_query() are appearing in the error log:

• Table '...matomo_logtmpsegmentXXX' doesn't exist — from queries containing /* WP IGNORE ERROR */
• Unknown system variable 'TX_ISOLATION' — from SELECT @@TX_ISOLATION

This suggests the suppression is also not working during cron execution, not just on the system report page. The errors repeat in an alternating pattern across all 44 entries:

errors[0-1]  → matomo_logtmpsegmentXXX table doesn't exist
errors[2]    → Unknown system variable 'TX_ISOLATION'
errors[3-4]  → matomo_logtmpsegmentXXX table doesn't exist
errors[5]    → Unknown system variable 'TX_ISOLATION'
... repeating

[diosmosis]

The error suppression mechanism itself is not affected by Matomo. I suspect this is an incorrect use of the set_error_handler() function somewhere (possibly Wonolog). Custom error handlers should check whether the specific warning is included in error_reporting() and avoid handling (unless the error handler specifically wants to handle silenced errors). See https://github.com/matomo-org/matomo/blob/5.x-dev/core/ErrorHandler.php#L142-L145. Can you check if any of your WordPress plugins have this problem?