Rust mysql_async interpreting table_name and is_nullable as empty strings from information_schema.columns in prepared statement

[mcronce]

Overview of the Issue

When running Prisma's integration tests against the MySQL 8.0 flavor of vttestserver specifically (MySQL 5.7, MySQL 8.0, and vttestserver:mysql57 all work fine), the results of the following query are being interpreted incorrectly by the client:

SELECT
    column_name column_name,
    data_type data_type,
    column_type full_data_type,
    character_maximum_length character_maximum_length,
    numeric_precision numeric_precision,
    numeric_scale numeric_scale,
    datetime_precision datetime_precision,
    column_default column_default,
    is_nullable is_nullable,
    extra extra,
    table_name table_name
FROM information_schema.columns
WHERE table_schema = ?
ORDER BY ordinal_position

Specifically, the table_name and is_nullable columns, at least on the first row, are being interpreted as empty strings.

When running the query manually from the MySQL CLI, everything comes out looking normal:

+-------------+-----------+----------------+--------------------------+-------------------+---------------+--------------------+----------------+-------------+-------+------------+
| column_name | data_type | full_data_type | character_maximum_length | numeric_precision | numeric_scale | datetime_precision | column_default | is_nullable | extra | table_name |
+-------------+-----------+----------------+--------------------------+-------------------+---------------+--------------------+----------------+-------------+-------+------------+
| one         | int       | int            |                     NULL |                10 |             0 |               NULL | NULL           | NO          |       | a          |
| two         | int       | int            |                     NULL |                10 |             0 |               NULL | NULL           | NO          |       | a          |
+-------------+-----------+----------------+--------------------------+-------------------+---------------+--------------------+----------------+-------------+-------+------------+

Reproduction Steps

The last test case in rust/mysql_async test in planetscale/vitess-framework-testing#130 covers this.

Binary version

$ vtcombo --version
Version: 10.0.0-SNAPSHOT (Git revision 0a9e2dd40 branch 'master') built on Mon Feb 22 14:17:55 UTC 2021 by vitess@6c9dd932706e using go1.15.6 linux/amd64

Operating system and Environment details

Inside the vitess/vttestserver:mysql80 container:

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

$ uname -sr
Linux 5.10.7-3-MANJARO

$ uname -m
x86_64

On the host:

$ cat /etc/os-release 
NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
PRETTY_NAME="Manjaro Linux"
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://manjaro.org/"
BUG_REPORT_URL="https://bugs.manjaro.org/"
LOGO=manjarolinux

$ uname -sr
Linux 5.10.7-3-MANJARO

$ uname -m
x86_64

Log Fragments

I0311 01:04:18.956546     687 engine.go:385] schema engine created [a], altered [], dropped []
I0311 01:04:19.781088     687 engine.go:385] schema engine created [], altered [a], dropped []
I0311 01:04:19.837391     687 engine.go:385] schema engine created [], altered [a], dropped []

[deepthi]

When running the query manually from the MySQL CLI, everything comes out looking normal:

Just checking, was this a MySQL 8.0 CLI?
Also does this happen with both PreparedStatements and not?

[mcronce]

$ mysql --version
mysql  Ver 15.1 Distrib 10.5.8-MariaDB, for Linux (x86_64) using readline 5.1

That's the CLI I have installed - I'll add a case for testing this with a plaintext query and get back to you on the second question

[mcronce]

Without using a prepared statement, the data is correct

[mcronce]

Looking at a packet capture, it looks like Vitess is at least trying to return the correct data. I see NO and a in the raw data twice, which is what I should see. Maybe something protocol-level?

[mcronce]

Two pcaps:

• One against vitess/vttestserver:mysql80: https://drive.google.com/file/d/1PoM5NnTq2bRJtHL4mPjvjTcDMx1Hs_qx/view
  • Packet 59 prepares the statement
  • Packets 63, 67, 71, 73, 75, 77, 79, 83, 85, 87, 89, 91, and 93 respond
  • Packet 97 executes the prepared statement
  • Packet 101 responds
• One against mysql:8.0: https://drive.google.com/file/d/10DtH8YRtQR_Hrn-ZuME6-Y_ps0DrRmnH/view
  • Packet 63 prepares the statement
  • Packet 67 responds
  • Packet 71 executes the prepared statement
  • Packet 75 responds

[mcronce]

Just for good measure, added one for vitess/vttestserver:mysql57: https://drive.google.com/file/d/1rVd9XMlH4B1qrLW7OpNYfu6vClPizOnt/view?usp=sharing

• Packet 59 prepares the statement
• Packets 63, 67, 71, 73, 75, 79, 81, 83, 85, 87, 89, 91, and 93 respond
• Packet 97 executes the prepared statement
• Packet 101 responds

[harshit-gangal]

I tried the test present in planetscale/vitess-framework-testing#130 on my local Vitess cluster and it does not fail

[deepthi]

I tried the test present in planetscale/vitess-framework-testing#130 on my local Vitess cluster and it does not fail

Are you saying that you can't reproduce the error? Or that #7685 fixes this?

[harshit-gangal]

I am not seeing this error using this branch locally.

#7685 is unrelated.

[mcronce]

I just pulled fresh vttestserver images to see if it happens to have been fixed in the interim, but I'm still seeing it. @harshit-gangal what's the exact command you're using to execute the test?

[harshit-gangal]

I have Vitess cluster running and executed cargo run --color=always --package mysql-test --bin mysql-test

[harshit-gangal]

@mcronce can you confirm with the new version of vttestserver that the issue is fixed?

[mcronce]

@harshit-gangal I tested rust/mysql and rust/mysql_async with vttestserver:mysql57 and vttestserver:mysql80, and all combinations pass :)

[harshit-gangal]

Closing as the issue does not exists.