launchbadge
Protocol Compatibility Issue with Aliyun MySQL/MariaDB: PREPARE_OK returns 7 bytes instead of standard 12 bytes
I have found these related issues/pull requests
I have searched by clicking HERE for existing issues, these are the ones I've found, and this is why I think this deserves a new issue.
[Note: You'll need to actually search and list any relevant existing issues here, or explain why this is different]
Description
When connecting to Aliyun's MySQL 8.0 (which appears to be based on MariaDB), the PREPARE_OK response packet returns only 7 bytes instead of the standard 12 bytes defined in MySQL protocol.
Expected behavior: Standard MySQL PREPARE_OK packet (12 bytes):
text [status:1] [statement_id:4] [columns:2] [params:2] [reserved:1] [warnings:2]
Actual behavior from Aliyun: Aliyun returns 7 bytes: [00, 00, 00, 02, 00, 00, 00]
Error encountered: After parsing, we get statement_id = 2, but subsequent operations fail with:
text "Unknown prepared statement handler (2) given to mysql_stmt_precheck"
Debug information:
Raw bytes received: [00, 00, 00, 02, 00, 00, 00]
Current parsing attempts (treating position 2 as status byte) yield statement_id = 2
The database rejects this statement_id, suggesting our parsing is incorrect
Other drivers (like Go MySQL driver) can connect successfully, indicating there's a compatible way to parse this
Reproduction steps
1、Set up a connection to Aliyun MySQL 8.0 database
2、Execute a prepared statement query
3、Observe the PREPARE_OK response packet in the protocol parser
4、The packet will be 7 bytes instead of the expected 12 bytes
SQLx version
0.8.6
Enabled SQLx features
"runtime-tokio", "tls-native-tls" ,"mysql","postgres","chrono", "bigdecimal"
Database server and version
Aliyun MySQL 8.0 (MariaDB-based)
Operating system
macOS Ventura 13.7.8
Rust version
1.90.0
Thanks for confirming! While similar to #3335, the Aliyun case is particularly significant because:
- It's a major cloud service used by many developers
- Other drivers (Go MySQL driver) handle it successfully
- The 7-byte format
[00, 00, 00, 02, 00, 00, 00]is consistent and could be parsed with specific logic
Given that other drivers demonstrate this is solvable, would SQLx be open to a PR that adds Aliyun compatibility? This would greatly improve SQLx's usability in Aliyun environments.