# Expected Diagnosis: ticdc-dataflow-stall-during-incident-window

This case should converge on a downstream TiCDC pipeline stall rather than a
source-side no-data explanation. Puller still has upstream activity, but the
post-puller stages are largely blocked at the Kafka sink path, with repeated
EOF / broken-pipe / TLS close-notify failures against the downstream Kafka
proxy while checkpoint lag keeps building up behind them.

The expected evidence chain is:

- Targeted TiCDC logs are collected for the reported window.
- The logs show Kafka/Sarama connection failures, such as
  `client/metadata got error from broker`, `EOF`, `write: broken pipe`, or
  `failed to send closeNotify alert`.
- Supporting TiCDC downstream-stall signals are present, such as
  `schedulerv3: slow table`, `checkpointLag=...`, `tableStatus=Replicating`,
  or a steadily growing `owner_ckp_lag` / frozen checkpoint pattern.
- The answer explains that the bottleneck is after puller, so the presence of
  puller traffic does not contradict the downstream near-zero throughput.
- Recommended follow-up should align with Kafka proxy / broker connectivity,
  TLS, or sink-side network-path investigation.