2 Commits (feature/pgsql-native-backend-protocol)

Author	SHA1	Message	Date
Rene Cannao	e68f72cf99	test(mysqlx): add diag logging + fix broken plan/schema in unit tests ... Two related changes to all mysqlx_*_unit-t.cpp files. # 1. Diagnostic logging across all 21 mysqlx unit tests Before this commit none of the mysqlx unit tests emitted any output beyond raw TAP `ok N`/`not ok N` lines. When CI-unit-tests-asan- coverage hung mid-run on plugin-chassis (run 25021206900), the per- test log file showed `ok 1 ... ok 6` and then nothing for ~110 minutes until the workflow's 120-minute timeout killed the job. We could not even tell *which* test was hung — the bash loop in the workflow only logs `PASS:`/`FAIL:` after a binary exits. Each binary now does: - `setvbuf(stdout, nullptr, _IOLBF, 0)` as the first statement of main(). Without this, when CI redirects stdout to a file the default block-buffered mode swallows any output that hasn't filled a 4KB-ish buffer — including diag lines emitted just before a blocking syscall. Line-buffering means each `\n`-terminated diag is flushed before the syscall, so a hang has 1-line-resolution attribution in the log. - `diag("=== <filename> starting ===")` right after `plan(...)`, so the log always has at least one line proving the binary loaded and reached main() (rules out crashes during static init). - `diag(">>> %s", __func__)` at the top of every `static void test_*()` subtest function called from main(), so a hang or assertion failure points at the responsible subtest. - In `mysqlx_concurrent_unit-t`, additional checkpoint diags inside `test_concurrent_handshakes` ("starting Mysqlx_Thread", "spawning N clients", "all clients spawned, joining", ..., "thr.stop() returned") since the surrounding test was the one that actually hung in CI; this gives a 7-checkpoint resolution within the body. This change is the reason we were able to bisect the listener O_NONBLOCK bug fixed in the previous commit: with these diags the hang point ("all clients spawned, joining" → never reached "all clients joined, sleeping 500ms") was visible in the per-test log within seconds of running it. # 2. Plan/fixture corrections in 4 tests that never actually passed These tests were green in CI by virtue of nothing in the workflow checking their exit codes (CI-mysqlx exercised a different path); the moment CI-unit-tests-asan-coverage started actually running them they came back red. Each was a real bug in the test harness, not in the production code: - mysqlx_backend_auth_unit-t.cpp: plan(42) but only 34 ok() can fire on the success path. State_transitions emits 23, the remaining six functions emit 11 — total 34. plan(42) was never reachable; fixed to plan(34). - mysqlx_session_unit-t.cpp: plan(62) but only 60 fire. Four `ok( false, ...)` lines live in protobuf-parse failure branches that the success path skips; fixed to plan(60). - mysqlx_config_store_unit-t.cpp: load_from_runtime() SELECTs from runtime_mysqlx_variables (the variables table the production code uses to pick up thread_pool_size / connect_timeout / tls_mode / max_cached_connections at runtime), but the test's fixture only created 3 of the 4 mysqlx tables. Added kRuntimeMysqlxVariablesDdl and the matching execute() — same shape the sibling mysqlx_config_store_concurrent_unit-t already uses. - mysqlx_route_store_unit-t.cpp: ad-hoc minimal DDL for runtime_mysql_users / runtime_mysql_servers omitted columns the production query SELECTs (password, weight). Switched to the canonical ADMIN_SQLITE_RUNTIME_MYSQL_USERS and ADMIN_SQLITE_TABLE_RUNTIME_MYSQL_SERVERS macros and added the runtime_mysqlx_variables table. After this commit `for t in mysqlx_*_unit-t; do ./$t; done` is 21/21 green (754 ok asserts total, 0 not_ok, 0 timeouts), 10/10 stable across repeated runs of the previously-flaky mysqlx_concurrent_unit-t.	2 months ago
Rene Cannao	19dc8310fe	test(mysqlx): add concurrent session test for v2 event-driven architecture ... Tests that a single Mysqlx_Thread can handle 20 concurrent X Protocol sessions without blocking. Each client connects, sends CapabilitiesGet, and reads the response. All sessions complete successfully because the thread's poll() loop multiplexes I/O across all sessions cooperatively — no session blocks another. This validates the core architectural difference from Phase 1: - Phase 1: 1 thread, 1 session at a time, blocking - Phase 2: 1 thread, N sessions concurrent, non-blocking	3 months ago