# Inconsistent Store Liveness Between Region Cache and Store Cache When Follower Read Is Enabled

Source note: adapted from the Feishu `Transaction oncall handbook` <https://pingcap.feishu.cn/wiki/FF5Jwc1EniDGZPk31jJcvSXDnPe>.

- Phenomenon:
  - Requests continue to use follower-read paths incorrectly after a TiKV or TiFlash store updates its address or labels.
  - Some cached regions keep treating the old replica state as unavailable, while newly accessed regions behave normally.
- Trigger / Preconditions:
  - Follower read is enabled, for example through prefer-leader or similar replica-read behavior.
  - A TiKV or TiFlash store changes its address or labels and comes back with updated metadata.
- Key logs:

```text
[INFO] [store_cache.go:487] ["store address or labels changed, add new store and mark old store deleted"] [store=100][old-addr=tikv-old-address...]
[INFO] [store_cache.go:648] ["[health check] store became reachable"] [storeID=100]
```

- Key metrics:
  - Most requests still go through follower read even though prefer-leader is enabled.
  - The related TiKV can still show some QPS, which makes the incident look partial instead of total.
- Root cause:
  - `client-go` creates a new store object in store-cache when address or label metadata changes.
  - Region-cache may still hold the old store pointer.
  - Existing cached regions and newly accessed regions therefore observe different liveness state for what is logically the same store ID.
- Workaround:
  - Restart the affected TiDB instance so region-cache and store-cache are rebuilt consistently.
- Fixed version:
  - Check the release line associated with `client-go#1823` / `client-go#1826` before relying on version-only mitigation.
- Related oncall:
  - v8.5.5 inconsistent store liveness between region-cache and store-cache when follower-read enabled `GTOC-8095`