# TiCDC Replication Progress

## Question

Is lag produced before ResolvedTS advances or between ResolvedTS and
CheckpointTS, and which architecture-specific upstream or downstream stage is
blocked?

## Enter When

Use for checkpoint/resolved-ts lag, initial or incremental scan, puller/Event
Service/Event Store/dispatcher progress, sink delay, downstream acknowledgement,
redo, barrier, or a running changefeed whose progress is stuck.

## First Batch

1. Resolve the exact changefeed and the strongest available TiCDC version,
   deployment, and kernel-architecture facts before selecting metric families.
   For Wetech OP, use its routed runtime metric/log contract and supplied task
   context; do not require Cloud Dataflow metadata.
2. Compare same-changefeed ResolvedTS lag and CheckpointTS lag over the incident
   window. Do not compare different labels, windows, or recording rules.
3. If both rise, inspect the upstream branch: TiKV minimum resolved-ts/CDC scan,
   classic puller/processor, or new-architecture Log Puller, Event Service,
   Event Store, and dispatcher progress.
4. If ResolvedTS stays normal while CheckpointTS rises, inspect the downstream
   branch: sink queue/write latency/error, DDL/barrier, worker/partition skew,
   Kafka acknowledgement/retry, cloud-storage spool, or downstream capacity.

## Decision

Growing ResolvedTS lag localizes the path upstream of resolved progress. Normal
ResolvedTS with growing CheckpointTS lag localizes it downstream. A healthy
cluster-wide series does not negate one affected changefeed; an empty or failed
query is a gap, not healthy evidence.

## Strongest Alternative And Stop

Check one adjacent stage on the opposite side of the ResolvedTS/CheckpointTS
boundary. Stop after the blocked stage and strongest material alternative are
bounded. Never pause, resume, remove, recreate, or reconfigure a changefeed.