dangmingyang opened a new issue, #38717: URL: https://github.com/apache/shardingsphere/issues/38717
## Bug Report **For English only**, other languages will not accept. Before report a bug, make sure you have: - Searched open and closed [GitHub issues](https://github.com/apache/shardingsphere/issues). - Read documentation: [ShardingSphere Doc](https://shardingsphere.apache.org/document/current/en/overview). Please pay attention on issues you submitted, because we maybe need more details. If no response anymore and we cannot reproduce it on current information, we will **close it**. Please answer these questions before submitting your issue. Thanks! ### Which version of ShardingSphere did you use? 5.5.3 ### Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy? ShardingSphere-Proxy ### Expected behavior Inserting an explicit value into an `AUTO_INCREMENT` column is legal MySQL, including a negative value when the column is **signed** (`int`, not `int unsigned`). Native MySQL accepts it, stores it, and — because the value was **supplied by the client, not generated** — reports **no** generated key (`Statement.getGeneratedKeys()` returns an empty result set, `LAST_INSERT_ID()` is unchanged). Through the Proxy the result should be identical: the row is written and **no spurious generated key / `last_insert_id` is fabricated and returned to the client**. ### Actual behavior With an `ENCRYPT` rule covering the table (any rule that makes ShardingSphere treat the table as rule-managed), the following `INSERT` returns an error to the client: ``` SQL Error [22001]: Data truncation: Value '18446744073709551613' is outside of valid range for type java.lang.Long ``` …**but the row is actually committed** to the backend (a subsequent `SELECT` shows it). So the client sees a failure while the data is in fact persisted. The reported number is not random: ``` -3 as two's-complement 64-bit = 0xFFFFFFFFFFFFFFFD interpreted as UNSIGNED = 18446744073709551613 = 2^64 - 3 java.lang.Long max = 9223372036854775807 (2^63 - 1) 18446744073709551613 > Long.MAX -> overflow -> [22001] ``` i.e. the explicit value `-3` has been re-interpreted as an **unsigned 64-bit integer** somewhere on the response path, and the client's MySQL Connector/J then refuses to read it back as a signed `Long`. ### Reason analyze (If you can) ### Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc. 1. On the backend MySQL, create a table with a **signed** auto-increment PK: ```sql CREATE TABLE `dmy_1` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(100) DEFAULT NULL, `pwd` varchar(620) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci; ``` 2. Add an `ENCRYPT` rule that covers the table (e.g. encrypt `pwd`), so the table is rule-managed: ```sql -- via DistSQL, or equivalent YAML CREATE ENCRYPT RULE dmy_1 ( COLUMNS((NAME=pwd, CIPHER=pwd, ENCRYPT_ALGORITHM(TYPE(NAME='AES', PROPERTIES('aes-key-value'='123456abc'))))) ); ``` 3. Connect to the **Proxy** with a MySQL client (JDBC / MySQL Connector/J) and run: ```sql INSERT INTO dmy_1 (id, name, pwd) VALUES (-3, 'wangwu', '111111'); ``` → `[22001] Data truncation: Value '18446744073709551613' is outside of valid range for type java.lang.Long`. ### Example codes for reproduce this issue (such as a github link). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
