Upgrade to 6.2.2 confuses SQL clients

MaxScale with rw-spit and one primary, one replica. Testing platform with a few pretty standard WordPress web sites (PHP 7.2 on RHEL-8). After the upgrade of MaxScale from 6.2.1 to 6.2.2 they practically stopped loading (with very few exceptions now and then, mostly around a restart of some component like PHP-FPM or MaxScale).

The primary node shows the SQL client connect (so authentication works fine), but even the default database is not set (which is unusual - the typical connection will always set a default database). Then the connection remains idle until terminated on timeout. So, the client side seems to be somehow stuck, although the PHP FPM error log says nothing about this. The MaxScale log is also completely silent - no crashes or restarts of the process detected.

Even an old MariaDB client like 10.3 has no problems connecting and working via MaxScale. However, apparently some SQL clients do have an issue.

Reverting MaxScale back to 6.2.1 restores the web sites to working condition.

Looking at MXS-4028, causal reads are enabled, but at global level. Here is the relevant part of the (otherwise simple) RW split:

[172.16.69.4-Service]
type=service
router=readwritesplit
servers=172.16.69.2,172.16.69.3
enable_root_user=1
user=maxscale
password=*****
use_sql_variables_in=master
max_slave_connections=1
max_slave_replication_lag=1s
causal_reads=global
filters=QLA_Filter

The CPU on the MaxScale machine is practically idle, free memory is available, disk space too.

We cannot offer a definitive reproduction scenario, but it may be worth simulating with a PHP-7.2 client (stock on RHEL-8); I think WP uses the mysqli driver from it.