# [Known Issue] TiDB panic when `tidb_replica_read` is `closest-adaptive` ([tidb#60175](https://github.com/pingcap/tidb/issues/60175))

Source note: adapted from GitHub issue [tidb#60175](https://github.com/pingcap/tidb/issues/60175).

## Issue

- Link: [tidb#60175](https://github.com/pingcap/tidb/issues/60175)
- Summary: when `tidb_replica_read` is set to `closest-adaptive`, TiDB may panic while selecting the target replica for a read request. This setting was the default for newly created v7.5.6 cloud clusters.

## Phenomenon

- SQL execution panics in the coprocessor read path instead of returning a normal query error.
- The stack trace usually includes replica-selection code such as `IsLabelsMatch`, `accessFollower.isCandidate`, and `replicaSelector.next`.

Example panic stack:

```text
github.com/pingcap/tidb/pkg/store/copr.(*copIteratorWorker).handleTask.func1
    /workspace/source/tidb/pkg/store/copr/coprocessor.go:1116
runtime.gopanic
    /usr/local/go/src/runtime/panic.go:914
runtime.panicmem
    /usr/local/go/src/runtime/panic.go:261
runtime.sigpanic
    /usr/local/go/src/runtime/signal_unix.go:861
github.com/tikv/client-go/v2/internal/locate.(*Store).IsLabelsMatch
    /root/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.8-0.20250226073831-d4383a9a6811/internal/locate/region_cache.go:2780
github.com/tikv/client-go/v2/internal/locate.(*accessFollower).isCandidate
    /root/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.8-0.20250226073831-d4383a9a6811/internal/locate/region_request.go:1020
github.com/tikv/client-go/v2/internal/locate.(*accessFollower).next
    /root/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.8-0.20250226073831-d4383a9a6811/internal/locate/region_request.go:906
github.com/tikv/client-go/v2/internal/locate.(*replicaSelector).next
    /root/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.8-0.20250226073831-d4383a9a6811/internal/locate/region_request.go:1178
github.com/tikv/client-go/v2/internal/locate.(*RegionRequestSender).getRPCContext
    /root/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.8-0.20250226073831-d4383a9a6811/internal/locate/region_request.go:1478
github.com/tikv/client-go/v2/internal/locate.(*RegionRequestSender).SendReqCtx
    /root/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.8-0.20250226073831-d4383a9a6811/internal/locate/region_request.go:1608
github.com/tikv/client-go/v2/txnkv/txnsnapshot.(*ClientHelper).SendReqCtx
    /root/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.8-0.20250226073831-d4383a9a6811/txnkv/txnsnapshot/client_helper.go:149
github.com/pingcap/tidb/pkg/store/copr.(*copIteratorWorker).handleTaskOnce
    /workspace/source/tidb/pkg/store/copr/coprocessor.go:1234
github.com/pingcap/tidb/pkg/store/copr.(*copIteratorWorker).handleTask
    /workspace/source/tidb/pkg/store/copr/coprocessor.go:1126
github.com/pingcap/tidb/pkg/store/copr.(*copIteratorWorker).run
    /workspace/source/tidb/pkg/store/copr/coprocessor.go:799
runtime.goexit
    /usr/local/go/src/runtime/asm_arm64.s:1197
```

## Root Cause

The bug is triggered in the `closest-adaptive` replica-selection path. When TiDB evaluates follower candidates and matches store labels, the client-go locator path may dereference invalid state and panic instead of safely skipping the candidate or falling back to another replica.

From the stack trace, the failure happens during:

- `github.com/tikv/client-go/v2/internal/locate.(*Store).IsLabelsMatch`
- `github.com/tikv/client-go/v2/internal/locate.(*accessFollower).isCandidate`
- `github.com/tikv/client-go/v2/internal/locate.(*replicaSelector).next`

In practice, this means the issue is specific to replica selection logic rather than the SQL layer itself.

## Diagnostic Steps

1. After the panic occurs, check whether `tidb_replica_read` is set to `closest-adaptive`:

```sql
SHOW VARIABLES LIKE 'tidb_replica_read';
```

1. Confirm that the panic stack contains the replica-selection path shown above, especially `IsLabelsMatch` or `accessFollower.isCandidate`.

1. If the cluster is a newly created cloud v7.5.6 cluster, treat `closest-adaptive` as a strong signal because it was the default setting there.

1. Change `tidb_replica_read` temporarily to `closest-replicas` or `leader` and retry the same SQL. If the panic disappears, the issue is very likely this bug.

## Workaround

Change `tidb_replica_read` to `closest-replicas` or `leader` to bypass the buggy `closest-adaptive` path:

```sql
SET GLOBAL tidb_replica_read = 'closest-replicas';
-- or
SET GLOBAL tidb_replica_read = 'leader';
```

If only a session-level mitigation is needed, use `SET SESSION` instead.

## Affected Version

- v8.5
- v8.1
- v7.5

## Fixed Version

- v8.5.3
- v8.1.3
- v7.5.7
- v7.1.7

## Related Oncall

- v7.5.6 invalid memory address causing SQL panic TCID-11399 / TCOC-3308