MySQL 9.x: test_log_last_insert_id-t fails — expected 7 logged queries, got 6

[renecannao]

Symptom

TAP test test_log_last_insert_id-t (group mysql90-g3) fails on MySQL 9.0.1:

ok 1 - ...
ok 2 - ...
ok 3 - Detected last_insert_id: 3 , expected: 3
not ok 4 - Expected queries: 7, actual: 6
# Failed 1 tests!
TAP test 262/325 'test_log_last_insert_id-t' RC: 1

The assertion is at test/tap/tests/test_log_last_insert_id-t.cpp:104:

ok(nentries == 7, "Expected queries: 7, actual: %d", nentries);

Context

The test counts entries in ProxySQL's query log produced while running a small workload that verifies last_insert_id tracking. The feature-level assertion (ok 3 - Detected last_insert_id: 3, expected: 3) passes — last_insert_id tracking itself is working correctly on 9.x.

What's off is the TOTAL count of logged query entries: 6 observed vs 7 expected. One query the test expected to be logged isn't being logged on a MySQL 9.0 backend. On 8.4 backends the same test passes with nentries == 7.

Analysis (first pass)

The test's last captured log entry was:

{"client":"192.168.48.4:42346","digest":"0x47B278EE303E9CCE",
 "duration_us":371,"endtime":"2026-04-16 05:33:26.084717",
 ...,"event":"COM_QUERY","hostgroup_id":3100,"last_insert_id":3,
 "query":"INSERT INTO test.test_insert_id VALUES (NULL)",
 "rows_affected":1,"rows_sent":0,...,"username":"testuser"}

So the INSERT was logged. One of the auxiliary queries (likely a SELECT LAST_INSERT_ID() or a SET / USE / initial setup) that's logged on 8.4 is no longer being logged on 9.0. Plausible causes:

• MySQL 9.x may no longer need/emit one of the internal warm-up queries that ProxySQL's log watcher picked up on 8.4 (e.g. a SELECT @@session.tx_read_only dropped from the handshake).
• The event-logger may not be logging a COM that changed type on 9.x.
• ProxySQL's own internal-query filter (what's logged vs. not) may have changed behaviour for a query type that 9.x emits differently.

Not yet drilled all the way to the missing query. Evidence is in:
ci_infra_logs/mysql90-g3-myrun3/tests/proxysql-tester.py/tests/test_log_last_insert_id-t.log

Scope / urgency

• Test passes on mysql57, mysql84; fails on mysql90 (and likely mysql95).
• Low real-world impact: the feature under test (last_insert_id logging) works. Only the count of logged entries shifted by 1. The test expectation is hardcoded.
• Fix options: (a) tighten the test to assert on specific-query-logged conditions rather than raw count, (b) make the count expected-range variable by backend version, or (c) investigate and restore the missing log entry if it represents real coverage loss.

Related

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

[coderabbitai]

🔗 Related PRs

#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]
#5545 - feat(ffto): record error details from fast-forward sessions [merged]
#5559 - Fix crash when COM_BINLOG_DUMP received with idle backends (#5556) [merged]
#5612 - test(pgsql-ssl_keylog): fix container-local path + NSS label regex [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]

Likely addressed by PR #5625 (commit 7c6f42b — re-enabled PROXYSQL FLUSH LOGS before reading the log file, since eventslog_flush_timeout=0 alone still races the periodic flush thread). Marking to verify — please re-run test_log_last_insert_id-t against MySQL 9.x and confirm.