Describe the bug
Host Test Results has a field labeled "Database Version". Right now, the runner
fills mysql_version with output from mysql --version.
That command tells us which MySQL/MariaDB client binary is installed where the
runner runs. It does not tell us which database server WordPress used for the
test.
That makes the field misleading and a client version is not really useful.
"Database Version" reads as, and should be, the server version. When we are
comparing MySQL/MariaDB results or trying to understand a failure, we'll want the specific server version.
To Reproduce
Review recent tests or perform a new test and examine env.json.
Today it can contain a client binary string, for example:
mysql Ver 15.1 Distrib 10.4.12-MariaDB, for debian-linux-gnu ...
Expected behavior
When the runner can connect to the configured test database safely,
mysql_version should contain the raw server version string, such as the value
returned by SELECT VERSION().
If the runner cannot detect the server version safely, it should leave the value
empty or absent so the current reporter displays Unknown. I would rather have
Unknown than a value we know points to the wrong thing.
It should not fall back to the client binary version.
Additional context
There is some history here:
I think the first PR should stay small:
- Preserve the existing
mysql_version env key for reporter compatibility.
- Keep the change runner-only.
- Store the raw server version string when detection succeeds.
- Use empty/unknown behavior when detection fails.
- Guard missing credentials, missing
mysqli, connection failure, query
failure, empty result rows, and PHP 8.1+ mysqli exception behavior.
- Do not add a client-version field in the first PR.
- Do not change reporter display, taxonomy behavior...etc.
Describe the bug
Host Test Results has a field labeled "Database Version". Right now, the runner
fills
mysql_versionwith output frommysql --version.That command tells us which MySQL/MariaDB client binary is installed where the
runner runs. It does not tell us which database server WordPress used for the
test.
That makes the field misleading and a client version is not really useful.
"Database Version" reads as, and should be, the server version. When we are
comparing MySQL/MariaDB results or trying to understand a failure, we'll want the specific server version.
To Reproduce
Review recent tests or perform a new test and examine env.json.
Today it can contain a client binary string, for example:
mysql Ver 15.1 Distrib 10.4.12-MariaDB, for debian-linux-gnu ...Expected behavior
When the runner can connect to the configured test database safely,
mysql_versionshould contain the raw server version string, such as the valuereturned by
SELECT VERSION().If the runner cannot detect the server version safely, it should leave the value
empty or absent so the current reporter displays
Unknown. I would rather haveUnknownthan a value we know points to the wrong thing.It should not fall back to the client binary version.
Additional context
There is some history here:
for MySQL/MariaDB version capture.
mysql_versionpath usingmysql --version.use the server version from
SELECT VERSION().client-version path after the server lookup broke tests. No root cause was reported, no errors...etc.
report-only/Core Docker flows where DB credentials may not be available. It's seperate from this issue wehre runners with DB creds are reporting the wrong info.
points back to this runner behavior and to
SELECT VERSION()as the bettersource for the database server version.
I think the first PR should stay small:
mysql_versionenv key for reporter compatibility.mysqli, connection failure, queryfailure, empty result rows, and PHP 8.1+
mysqliexception behavior.