String returned when DATETIME expected

[Robie Basak]

There is a ruby-mysql2 dep8 failure when run against mysql-8.0 8.0.28-0ubuntu3 in jammy-proposed but everything else from the Jammy release pocket. It doesn't fail when run against the Jammy release pocket on its own which uses mysql-8.0 8.0.27-0ubuntu0.21.10.1.

Here's the failure:

https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/r/ruby-mysql2/20220220_133426_11d64@/log.gz

[Robie Basak (racb)]

I've gotten quite deep into this and am still working on it.

[Robie Basak (racb)]

I've written a reproducer, attached. Behaviour changes between 8.0.27-0ubuntu0.21.10.1 and 8.0.28-0ubuntu3. Before, running "SELECT ? AS a" as a parameterized query, supplying a MYSQL_TYPE_DATETIME using the MYSQL_TIME struct, then the result was a single row with one field with a MYSQL_TYPE_DATETIME object. After, the same thing results in a different type (I think a string). This is causing the ruby-mysql2 dep8 failure, because it assumes that a MYSQL_TYPE_DATETIME is returned in this case.

The MySQL 8.0.28 release notes discuss some changes to the way that types are interpreted: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html

However it's not clear to me that this behaviour change is intentional, and it seems reasonable to me that given the input type is known in this case, the output type should be the same. So it does seem like a MySQL upstream regression to me.

[Robie Basak (racb)]

Build the reproducer with "gcc -g -o reproducer reproducer.c -lmysqlclient" after installing build-essential and libmysqlclient-dev. By default you need to run it with sudo because mysql-server-8.0 configures root (domain socket authenticated) access only. Or give your user permission to connect to the default database.

[Robie Basak (racb)]

I've verified that this also affects Focal moving from the release pocket MySQL build (8.0.19-0ubuntu5) to the updates pocket (8.0.28-0ubuntu0.20.04.3) but with everything else fully up-to-date against the updates pocket.

I'm not sure what, if anything, we can do about this besides an upstream report, but I'm tagging it regression-update for statistics.

[Robie Basak (racb)]

Lars, please could you take a look, and file a bug upstream if you agree?

For ruby-mysql2 in Jammy, maybe we just need to hint it through or patch and disable the tests or something, because there's nothing we can really do to change MySQL's behaviour here, and it's already in the stable releases for security reasons.

[Utkarsh Gupta (utkarsh)]

Whilst it's actually MySQL introducing a breaking change, I think I can do something on the ruby-mysql2 side. Taking a look! :)

[Lars Tangvald (lars-tangvald)]

We're looking into it, will get back to you when I know more :)

[Lars Tangvald (lars-tangvald)]

I think this is the same issue as reported in https://bugs.mysql.com/bug.php?id=106352 (which will be fixed in upcoming 8.0.29)

[Utkarsh Gupta (utkarsh)]

Awesome, 3h ago, I uploaded a work around, so this won't be a problem anymore. I'll revert the patch once we land 8.0.29. \o/

[Robie Basak (racb)]

Yes that looks like it. Thanks Lars!

[Utkarsh Gupta (utkarsh)]

Lars, do we have this fixing commit, though, for mysql?

[Robie Basak (racb)]

I don't think there's anything further for us to do in Ubuntu unless a patch becomes available or until 8.0.29 is released, so I'm moving it back to Triaged and unassigning it for now.