dbapi instrumentation does not work for MySQLdb/mysqlclient

[alisonatwork]

Describe your environment

Running Python 3 on WSL. Latest OpenTelemetry.

$ uname -srv
Linux 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021
$ python --version
Python 3.10.6
$ pip freeze | egrep '(opentelem|mysql)'
mysqlclient==2.0.3
opentelemetry-api==1.12.0
opentelemetry-instrumentation==0.33b0
opentelemetry-instrumentation-dbapi==0.33b0
opentelemetry-instrumentation-wsgi==0.33b0
opentelemetry-sdk==1.12.0
opentelemetry-semantic-conventions==0.33b0
opentelemetry-util-http==0.33b0

Steps to reproduce

For some reason when wrapping the connect function of MySQLdb, the supplied connections come back not connected.

$ python
Python 3.10.6 (main, Aug  2 2022, 00:00:00) [GCC 12.1.1 20220507 (Red Hat 12.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import MySQLdb as mysql
>>> c = mysql.connect(host="AAA",password="BBB",user="CCC")
>>> c
<_mysql.connection open to 'AAA' at 0x555c85535c00>
>>> c.get_server_info()
'8.0.30'
>>> c.close()
>>> c
<_mysql.connection closed at 0x555c85535c00>
>>> from opentelemetry.instrumentation.dbapi import trace_integration
>>> trace_integration(mysql, "connect", "mysql")
>>> c = mysql.connect(host="AAA",password="BBB",user="CCC")
>>> c
<_mysql.connection closed at 0x555c857ab600>
>>> c.get_server_info()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MySQLdb._exceptions.OperationalError: (2006, '')

What is the expected behavior?

I would expect to get a usable connection back.

What is the actual behavior?

The connection comes back already closed. It's really weird because if you put some breakpoints you can see that the actual backing Connection object to MySQL is open, but the TracedConnectionProxy object somehow thinks that it is closed. So when you try to do anything with the connection it throws MySQLdb._exceptions.OperationalError: (2006, '') (database is gone). It seems like somehow there is a state in the connection object which the proxy object is not copying somehow, but I can't figure out what it is.

Additional context

MySQLdb is a MySQL client library that wraps around the C libmysqlclient, so perhaps it's something about going across languages that is causing strange things to happen here.

[alisonatwork]

Not sure if it's helpful, but I was able to create a workaround for my case by not wrapping the connection and instead just manually creating a DatabaseApiIntegration after connect, then manually wrapping the cursors with get_traced_cursor_proxy at query time. It's a bunch of extra (messy) code, though. It would be nice if there was a way for the dbapi instrumentation library to cleanly wrap a MySQLdb connection.

[tbbream]

I also just got hit by this trying to upgrade the OpenTelemetry SDK and instrumentation version.

It looks like it broke in the 0.32b0 release with this commit. From what I could tell, the connection is now closed when it is leaving the connect function, which leads to the auto commit call to fail with the OperationalError. However, going back to the wrapt.ObjectProxy keeps this working.

[tbbream]

@ocelotl I just wanted to bring it to your attention. I wasn't able to determine the difference in the approach that lead to the new style causing the connection to always be closed leading to this issue. It seems like the easiest solution would be to rollback the commit, but there might be more context that what I can see for the new approach and fixing it forward.

[ocelotl]

@ocelotl I just wanted to bring it to your attention. I wasn't able to determine the difference in the approach that lead to the new style causing the connection to always be closed leading to this issue. It seems like the easiest solution would be to rollback the commit, but there might be more context that what I can see for the new approach and fixing it forward.

Thanks, will investigate 👍

[ocelotl]

@alisonatwork @tbbream please give it a try with #1183. I tried @alisonatwork example with the changes in #1183 and it worked without an error being raised.

[alisonatwork]

I have just run the test with the changes suggested in #1183 and now there is a different error:

MySQLdb._exceptions.OperationalError: (2002, "Can't connect to local server through socket '/var/lib/mysql/mysql.sock' (2)")

That shows that the original arguments (host, user, password) are not being passed and it's just trying to connect to the MySQL instance on the local socket as if no connect arguments had been supplied at all. The fix then is to subsequently also add args and kwargs to all of the get_traced_connection_proxy calls elsewhere in the file. I'll add a comment on the PR.