decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>] when querying MariaDB 11.4 using mysqlclient

[jflabelle81]

Description

Environment:

• MariaDB: 11.4
• Python: 3.9
• Django: tested with multiple versions (3.x, 4.x and 5.x)
• mysqlclient: tested with several versions, same issue across all

Issue: When running Django with the django.db.backends.mysql engine (using mysqlclient), the following error occurs: decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>]

Full traceback ends with: File "/home/.../site-packages/MySQLdb/cursors.py", line 339, in _fetch_row return self._result.fetch_row(size, self._fetch_type) decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>]

The same database and schema work immediately and without any change when switching to "pypi mysql-connector-python (with ENGINE = "mysql.connector.django"), and the same project also works on another server running MariaDB 10.6.

No data issues seem to exist in the database, numeric and decimal fields are valid. Tried adjusting SQL modes (STRICT_TRANS_TABLES, NO_ENGINE_SUBSTITUTION, etc.), column precision, and recreating affected rows, issue persists.

Additional Context:

• Same codebase and database work properly on MariaDB 10.6 with the same Python and Django setup.
• This suggests a compatibility issue between mysqlclient and MariaDB 11.4, possibly in the decimal conversion layer.

[methane]

please provide minimum reproducible example. e.g. schema, data, and code.

[jflabelle81]

project.zip

Hi,

I hope what I’m providing will be sufficient. I’ve included:

• The database schema (a dump created with --no-data)
• The Django project (without local_settings, media files or static files)
• The requirements.txt with all dependencies

I’m not sure if this will be enough, or if you absolutely need data as well. Preparing an anonymized dataset would be more complex, as I’d need to go through all the tables to scrub the data.

Please let me know if the current material is sufficient, or if you really need some sample data and what minimum would be acceptable.

[methane]

OK, Non minimal example is better than nothing. Please provide full stack trace too. Last line doesn't tell me which table and query caused this error.

[jflabelle81]

Voilà: stderr.txt

[methane]

I cannot reproduce. But I find some people reporting same issue. For example, https://github.com/saltstack/salt/issues/65414#issuecomment-3573421308

Maybe, it is relating to exact mariadbclient version. What is your environment and which version of libmariadbclient do you use? Can you reproduce it with docker?

[methane]

OK, I can reproduce now.

• alpine 3.14; mariadb-connector-c (3.1.13-r0); ng
• alpine 3.15; 3.1.13-r2; ng
• alpine 3.16; 3.1.13-r4; ng
• alpine 3.17; 3.3.3-r0; OK

What is your mariadb-connector version?

[jflabelle81]

Sorry for the delay in responding, we're clearly in different timezones! I've checked the mariadb-connector version on my CloudLinux/cPanel system:

[root@cp3 cloudlinux]# rpm -qa | grep -i mariadb-connector cpanel-mariadb-connector-3.3.13-2.cp108~el9.x86_64 cpanel-mariadb-connector-devel-3.3.13-2.cp108~el9.x86_64

So I'm running mariadb-connector version 3.3.13 (cPanel build for EL9). Based on your testing results, it looks like version 3.3.3+ works fine (marked as "OK"), and my version 3.3.13 should be good as well. Let me know if you need any additional information!

[methane]

This issue seems to be happening basically inside mariadb-connector-c, and it seems to depend on the build rather than the version.

I am not familiar with Alpine Linux, and I have never used Cloud Linux. I think it will take a long time to investigate the problem. I recommend contacting Cloud Linux or cPanel support.

The problem that is occurring is that after calling mysql_store_result(), when calling mysql_fetch_fields(), some fields of the MYSQL_FIELD structure are corrupted.

[jflabelle81]

Just a quick follow-up with what I got from CloudLinux support.

As you suggested, I opened a ticket with CloudLinux. They were able to reproduce the issue with a simple script (no Django involved), and they provided the following workaround:

export LD_PRELOAD=/usr/lib64/libmariadb.so.3

According to their explanation:

By setting LD_PRELOAD, we ensure that the application loads the correct MariaDB 11.4 library from /usr/lib64 before any other conflicting libraries are used.

I tested this on my side and can confirm:

With LD_PRELOAD=/usr/lib64/libmariadb.so.3 set, python manage.py shell works fine, simple queries via connection.cursor() work, Site.objects.get_current() no longer raises decimal.InvalidOperation, and the Django app runs normally using mysqlclient.

Without LD_PRELOAD, the decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'> error comes back.

Using mysql-connector-python also works, which matches your initial suspicion that the problem is in the MariaDB C connector build, not in mysqlclient itself.

CloudLinux also told me they are consulting their development team about this and will follow up on their side, so it really looks like an environment / mariadb-connector-c build issue specific to their packages.

Like you said, this is not a bug in mysqlclient itself, but rather in the MariaDB connector C build shipped by CloudLinux. Feel free to close this issue or leave it as a reference for others who might hit the same problem on CloudLinux + MariaDB 11.4.

CloudLinux has confirmed that their development team is now looking into this to provide a permanent fix for the affected packages. If I receive any further details or an updated package from them, I’ll post an update here so others can use it as a reference.

[methane]

@jflabelle81 Thank you for sharing the information.

Since this issue is occurring in other environments as well, it would be helpful if you could share follow-up information. To prevent this issue from being locked, I will keep this issue open for a while longer.