release-8.5: max_user_connections overflow closes connection without returning 1203
- Dominant language
- Go
- Stars
- 40.5k
- Forks
- 6.2k
- PR merge metrics
- PR metrics pending
Description
## Bug Report
### 1. Minimal reproduce step (Required)
On a TiDB v8.5.7 instance, create a user whose connection limit is one:
```sql
DROP USER IF EXISTS 'muc_test'@'%';
CREATE USER 'muc_test'@'%' IDENTIFIED BY 'muc_pwd'
WITH MAX_USER_CONNECTIONS 1;
```
Keep the first connection open:
```bash
mysql --protocol=tcp -h -P \
-umuc_test -pmuc_pwd -e 'SELECT SLEEP(30)' &
```
While it is sleeping, open a second connection:
```bash
mysql --protocol=tcp -h -P \
-umuc_test -pmuc_pwd -e 'SELECT 1'
```
Finally clean up the test user:
```sql
DROP USER 'muc_test'@'%';
```
### 2. What did you expect to see? (Required)
The second connection should be rejected with the MySQL-compatible error:
```text
ERROR 1203 (42000): User muc_test@% has exceeded the 'max_user_connections' resource
```
### 3. What did you see instead (Required)
On v8.5.7, the second connection is authenticated and then closed without receiving the 1203 error packet. With the MySQL 5.7 client, the observed result is:
```text
ERROR 2006 (HY000): MySQL server has gone away
```
The client exit code is 1. The TiDB server log records the underlying error as `server:1203`, but `pkg/server/server.go` logs the error and returns without writing it to the client.
### 4. What is your TiDB version? (Required)
```text
8.0.11-TiDB-v8.5.7
```
This is a release-8.5 regression related to #68965. The original implementation in #59197 performs a connection-limit check during the handshake, while the release-8.5 implementation only performs the rejecting check after the handshake has already returned OK. The feature tracking issue is #59203.
Contributor guide
Research direction
Start in pkg/server/server.go and trace the release-8.5 connection-limit check from the handshake through the point where server:1203 is logged. Reproduce the case with the supplied TiDB SQL and mysql commands, then verify that the second connection receives ERROR 1203 instead of being closed with ERROR 2006.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, mysql
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100