# Expected Diagnosis: tikv-node-stall-during-incident-window

This case should converge on a short single-TiKV stall path rather than a
generic query-plan, TiDB CPU, or application-only explanation. The expected
answer should identify a RocksDB default-CF compaction burst on one TiKV
instance, triggered around a Raft leadership or snapshot ingestion event, which
saturated the read/unified thread pool and caused a brief cluster-visible SQL
latency surge.

The expected evidence chain is:

- The primary symptom is a short latency stall in the incident window, with
  query latency increasing across TiDB while the suspicious component is a
  single TiKV instance.
- TiKV evidence shows node-local stall/saturation signals such as compaction
  activity, RocksDB/background CPU, raftstore or scheduler delays, read/unified
  pool queueing/rejection, or large gRPC/coprocessor wait spikes.
- The root-cause chain links a Raft leadership/snapshot/SST ingestion trigger
  and default-CF compaction pressure to read-pool queue overflow or request
  rejection, rather than treating slow SQL shape as the primary cause.
- Impact should mention the short outage-style cascade, including query
  failures, killed connections, or mass disconnections if observed.
- Recommended actions should target TiKV/node-level mitigation such as leader
  rebalancing, reducing large batch delete/tombstone pressure, reviewing RocksDB
  compaction sizing, and adding profiling or TopSQL follow-up.