# TiCDC Replication Correctness

## Question

Which exact table, row range, DDL, schema-tracker state, filter, syncpoint, or
recovery boundary explains the reported missing or inconsistent replication?

## Enter When

Use for a missing table or data, unexpected filtering/ineligible-table
behavior, DDL/schema-tracker errors, table rename, duplicate or inconsistent
rows, syncpoint mismatch, or restart/recovery correctness questions.

## First Batch

1. Resolve the exact changefeed and the strongest available independent TiCDC
   version, deployment, architecture, incident-window, downstream, and task
   state facts. For Wetech OP, Cloud Dataflow metadata is not applicable; use
   the routed runtime metrics/logs and supplied task context.
2. Align the exact table/DDL/error signature with changefeed logs and progress.
   Distinguish not selected, ineligible, filtered, schema-tracker failure,
   downstream apply failure, and progress not yet reaching the event.
3. For DDL or rename, preserve schema/table identity before and after the event.
   For syncpoint or restart, preserve the checkpoint/syncpoint boundary and
   whether the reported inconsistency predates recovery.
4. Treat skip-transaction, force-replicate, filter changes, checkpoint edits,
   and task recreation as data-affecting operations, never automatic fixes.

## Decision

Do not equate a running changefeed with complete replication. State the exact
correctness layer supported by positive evidence and keep downstream verification
or customer-owned application facts separate. Missing provider evidence cannot
prove data absence or safety.

## Strongest Alternative And Stop

Check the closest non-destructive alternative, usually filter/ineligibility
versus schema/downstream apply. Stop before recommending a mutation. Preserve
data-risk or recovery-safety cases for human ownership.