Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

• Searched open and closed GitHub issues.
• Read documentation: ShardingSphere Doc.

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:

   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:

   -- 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:

   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).