pingcap / pingcap/tidb

release-8.5: max_user_connections overflow closes connection without returning 1203

Open
#69,911 2 comments 0 reactions 0 assignees View on GitHub
severity/moderate sig/sql-infra type/bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.