MySQL 9.x: charset_unsigned_int-t — SET NAMES … COLLATE utf8mb4_croatian_ci ignored, connection stays on default

[renecannao]

Symptom

TAP test charset_unsigned_int-t (groups mysql90-g1, mysql95-g1) fails on MySQL 9.0 and 9.5:

not ok 2 - Backend is mysql version >= 8.0. Actual collation utf8mb4_general_ci

The assertion is at test/tap/tests/charset_unsigned_int-t.cpp:81:

ok(var_value.compare("utf8mb4_croatian_ci") == 0,
   "Backend is mysql version >= 8.0. Actual collation %s", var_value.c_str());

What the test does

From the file header:

Verifies that ProxySQL correctly handles character set and collation assignments, especially for collations with IDs > 255 (unsigned int). Tests:

1. 'SET NAMES' with high-numbered collations (e.g., utf8mb4_croatian_ci).
2. ...

Setup (lines 47, 69–81):

set_admin_global_variable(mysqlAdmin, "mysql-default_collation_connection", "utf8mb4_general_ci");
...
show_variable(mysql, var_collation_connection, var_value);   // expect: utf8mb4_general_ci from default
...
// execute: SET NAMES utf8mb4 COLLATE utf8mb4_croatian_ci
show_variable(mysql, var_collation_connection, var_value);
if (< 8.0) ok(... == "utf8mb4_general_ci", ...);       // line 79
else       ok(... == "utf8mb4_croatian_ci", ...);      // line 81  ← fails on 9.x

The SET NAMES … COLLATE utf8mb4_croatian_ci issued by the client is not being propagated to the backend: @@collation_connection still reads utf8mb4_general_ci (ProxySQL's default) instead of the explicitly-requested utf8mb4_croatian_ci.

Test passes on MySQL 8.4 — the feature works on 8.0+. Something about MySQL 9.x's protocol or ProxySQL's 9.x handling of SET NAMES ... COLLATE for > 255-ID collations regresses.

Likely root cause (hypothesis)

Collation IDs above 255 are transmitted as unsigned 16-bit integers in MySQL protocol messages (classic 2-byte collation field in handshake and COM_QUERY). On MySQL 9.x, collations like utf8mb4_croatian_ci may have been assigned IDs > 255 and ProxySQL's 9.x-path code may be truncating to uint8_t or mapping to an unexpected collation.

The comment in the test explicitly calls this out: "collations with IDs > 255 (unsigned int)" — this test was written to guard exactly this class of bug.

Companion issue

Very similar symptom in test_utf8mb4_as_ci-4841-t (separately filed). Both show the pattern "client sent SET NAMES ... COLLATE <specific>, backend reports utf8mb4_general_ci (ProxySQL's default)". Likely same ProxySQL 9.x code path.

Evidence: ci_infra_logs/mysql{90,95}-g1-myrun3/tests/proxysql-tester.py/tests/charset_unsigned_int-t.log

Related

Part of MySQL 9.x test-surface triage. Infrastructure: #5625.

[coderabbitai]

🔗 Related PRs

#5488 - Protocol encoding/decoding and utility unit tests (Phase 2.5) [merged]
#5528 - Run ProxySQL cluster inside single container + CI stability fixes [merged]
#5538 - CI test fixes: cluster sync, plan counts, test group assignments, and diagnostics [merged]
#5548 - Fix #5306 - SHOW WARNINGS with inline comments incorrectly sets warning_count [merged]
#5559 - Fix crash when COM_BINLOG_DUMP received with idle backends (#5556) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[renecannao]

Possibly addressed by PR #5625 (commit 7c6f42b — validate_charset now compares server_version as a numeric major instead of testing only the first character, so MySQL 9.x is handled like 8.x for collation ids >= 255). utf8mb4_croatian_ci is id 245 so the fix may not apply directly, but the same code path is involved — marking to verify on 9.x.