[PD API] stores/heartbeat is normal, but querying region-id=3249 returns ErrRegionNotFound. Down-peer checks show empty results (inconsistent state perspective/difficult to explain).

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

Environment/Deployment (for reproduction context, not for attribution)

OS: Ubuntu 22.04 (host machine)

Deployment: Docker Compose, 4 nodes (tidb1~tidb4)

PD exposed to host: http://127.0.0.1:12379

Reproduction Parameters: REGION_ID=3249, STORE_ID=5

Reproduction Steps (Executed on Host)

Record timestamps at the same point in time (for alignment troubleshooting):

date -u +%Y-%m-%dT%H:%M:%SZ
date -u +%s.%N

Query PD stores overview, single store, specified region, specified region operator, down-peer check, schedulers:

REGION_ID=3249
STORE_ID=5
PD=http://127.0.0.1:12379

curl -sS “$PD/pd/api/v1/stores” | head -c 200000; echo
curl -sS “$PD/pd/api/v1/store/$STORE_ID” | head -c 200000; echo
curl -sS “$PD/pd/api/v1/region/id/$REGION_ID” | head -c 200000; echo
curl -sS “$PD/pd/api/v1/operators/$REGION_ID” | head -c 200000; echo
curl -sS “$PD/pd/api/v1/regions/check/down-peer” | head -c 200000; echo
curl -sS “$PD/pd/api/v1/schedulers” | head -c 200000; echo

### 2. What did you expect to see? (Required)

At the same point in time, and when PD /pd/api/v1/stores shows each store state=Up with normal heartbeats:

If region-id=3249 is a valid region, then:

GET /pd/api/v1/region/id/3249 should return the region's details (peers/leader/down_peers/pending_peers, etc.), rather than directly returning ErrRegionNotFound.

If region-id=3249 has been removed via merge/split/GC, etc., then:

A more consistent/explainable perspective is desired (e.g., when troubleshooting down peers/abnormal regions, avoiding situations where “the region query fails to exist, yet the troubleshooting entry point relies on this region-id”). At minimum, it must be explicitly clarified whether this is expected behavior or an exception.

3. What did you see instead (Required)

At the same point in time:

2026-01-23T07:22:06Z
1769152926.532000134

(1) /pd/api/v1/stores showed all 4 stores as Up with normal heartbeats:

{
"count": 4,
"stores": [
{
"store": {
"id": 1,
"address": "tidb1:20160",
"version": "9.0.0-beta.1",
"peer_address": "tidb1:20160",
"status_address": "0.0.0.0:20180",
"git_hash": "0a97ca8ab18cdbcb626ee4e24b6db80ad472fd71",
"start_timestamp": 1768843787,
"deploy_path": "/opt/tidb/bin",
"last_heartbeat": 1769152917874583105,
"node_state": 1,
"state_name": "Up"
},
"status": {
"capacity": "1.441TiB",
"available": "647.8GiB",
"used_size": "15.11GiB",
"leader_count": 0,
"leader_weight": 1,
"leader_score": 0,
"leader_size": 0,
"region_count": 5,
"region_weight": 1,
"region_score": 250.60834039363482,
"region_size": 189,
"slow_score": 1,
"slow_trend": {
"cause_value": 250033.56506849316,
"cause_rate": 0,
"result_value": 0,
"result_rate": 0
},
"start_ts": "2026-01-19T17:29:47Z",
"last_heartbeat_ts": "2026-01-23T07:21:57.874583105Z",
"uptime": "85h52m10.874583105s"
}
},
{
"store": {
"id": 4,
"address": "tidb2:20160",
"version": "9.0.0-beta.1",
"peer_address": "tidb2:20160",
"status_address": "0.0.0.0:20180",
"git_hash": "0a97ca8ab18cdbcb626ee4e24b6db80ad472fd71",
"start_timestamp": 1768843787,
"deploy_path": "/opt/tidb/bin",
"last_heartbeat": 1769152917927503404,
"node_state": 1,
"state_name": "Up"
},
"status": {
"capacity": "1.441TiB",
"available": "647.8GiB",
"used_size": "15.24GiB",
"leader_count": 2,
"leader_weight": 1,
"leader_score": 2,
"leader_size": 177,
"region_count": 4,
"region_weight": 1,
"region_score": 249.2823703408156,
"region_size": 188,
"slow_score": 1,
"slow_trend": {
"cause_value": 250037.66609589042,
"cause_rate": 0,
"result_value": 34,
"result_rate": 0
},
"start_ts": "2026-01-19T17:29:47Z",
"last_heartbeat_ts": "2026-01-23T07:21:57.927503404Z",
"uptime": "85h52m10.927503404s"
}
},
{
"store": {
"id": 5,
"address": "tidb4:20160",
"version": "9.0.0-beta.1",
"peer_address": "tidb4:20160",
"status_address": "0.0.0.0:20180",
"git_hash": "0a97ca8ab18cdbcb626ee4e24b6db80ad472fd71",
"start_timestamp": 1768843787,
"deploy_path": "/opt/tidb/bin",
"last_heartbeat": 1769152918086751871,
"node_state": 1,
"state_name": "Up"
},
"status": {
"capacity": "1.441TiB",
"available": "647.8GiB",
"used_size": "15.14GiB",
"leader_count": 1,
"leader_weight": 1,
"leader_score": 1,
"leader_size": 1,
"region_count": 1,
"region_weight": 1,
"region_score": 1.3259700550086329,
"region_size": 1,
"slow_score": 1,
"slow_trend": {
"cause_value": 250034.58047945207,
"cause_rate": 0,
"result_value": 0,
"result_rate": 0
},
"start_ts": "2026-01-19T17:29:47Z",
"last_heartbeat_ts": "2026-01-23T07:21:58.086751871Z",
"uptime": "85h52m11.086751871s"
}
},
{
"store": {
"id": 6,
"address": "tidb3:20160",
"version": "9.0.0-beta.1",
"peer_address": "tidb3:20160",
"status_address": "0.0.0.0:20180",
"git_hash": "0a97ca8ab18cdbcb626ee4e24b6db80ad472fd71",
"start_timestamp": 1768843787,
"deploy_path": "/opt/tidb/bin",
"last_heartbeat": 1769152917869777978,
"node_state": 1,
"state_name": "Up"
},
"status": {
"capacity": "1.441TiB",
"available": "647.8GiB",
"used_size": "15.21GiB",
"leader_count": 2,
"leader_weight": 1,
"leader_score": 2,
"leader_size": 11,
"region_count": 5,
"region_weight": 1,
"region_score": 250.60834039575758,
"region_size": 189,
"slow_score": 1,
"slow_trend": {
"cause_value": 250041.35153583618,
"cause_rate": 0,
"result_value": 0,
"result_rate": 0
},
"start_ts": "2026-01-19T17:29:47Z",
"last_heartbeat_ts": "2026-01-23T07:21:57.869777978Z",
"uptime": "85h52m10.869777978s"
}
}
]
}

(2) /pd/api/v1/store/5 output:

{
“store”: {
“id”: 5,
“address”: “tidb4:20160”,
“version”: “9.0.0-beta.1”,
“peer_address”: “tidb4:20160”,
“status_address”: “0.0.0.0:20180”,
“git_hash”: “0a97ca8ab18cdbcb626ee4e24b6db80ad472fd71”,
“start_timestamp”: 1768843787,
“deploy_path”: “/opt/tidb/bin”,
“last_heartbeat”: 1769152918086751871,
“node_state”: 1,
“state_name”: “Up”
},
“status”: {
“capacity”: “1.441TiB”,
“available”: “647.8GiB”,
“used_size”: “15.14GiB”,
“leader_count”: 1,
“leader_weight”: 1,
“leader_score”: 1,
“leader_size”: 1,
“region_count”: 1,
“region_weight”: 1,
“region_score”: 1.3259700550086329,
“region_size”: 1,
“slow_score”: 1,
“slow_trend”: {
“cause_value”: 250034.58047945207,
“cause_rate”: 0,
“result_value”: 0,
“result_rate”: 0
},
“start_ts”: “2026-01-19T17:29:47Z”,
“last_heartbeat_ts”: “2026-01-23T07:21:58.086751871Z”,
“uptime”: “85h52m11.086751871s”
}
}

(3) Query for region-id=3249 returns not found:

“[PD:region:ErrRegionNotFound]region 3249 not found”

(4) Query for region-id=3249 returns not found:

“[PD:operator:ErrOperatorNotFound]operator not found”

(5) Down-peer check returns empty:

{“count”:0,“regions”:[]}

(6) Schedulers return normally:

[
“balance-region-scheduler”,
“balance-leader-scheduler”,
“balance-hot-region-scheduler”,
“evict-slow-store-scheduler”
]

Summary of Phenomenon: At the same point in time when both stores and heartbeats are functioning normally, region-id=3249 directly returns ErrRegionNotFound from the PD API perspective, and the down-peer check returns empty. This creates an inconsistent/unexplainable experience when troubleshooting a specific region's abnormal state, where the “critical region-id does not exist and the check entry yields no results.”

### 4. What is your TiDB version? (Required)

Release Version: v9.0.0-beta.1
Edition: Community
Git Commit Hash: 7aff918dcbfa6facf2adef9ade9961c40f217421
Git Branch: HEAD
UTC Build Time: 2025-03-24 09:09:55
GoVersion: go1.23.7
Race Enabled: false
Check Table Before Drop: false
Store: tikv