# TiCDC Canal-JSON WATERMARK by sink transport

First distinguish the sink transport. Do not apply an MQ message-stream
boundary to Cloud Storage data files.

Match answer depth to the customer's question:

- If the customer asks only what the event is or why it appears, explain its
  meaning, why it is emitted, and whether it represents business data.
- If the customer mistakes it for business data or unexplained noise, add one
  concise handling sentence. Do not add an unsolicited configuration inventory.
- Only when the customer asks how to disable, reduce, suppress, filter, or
  otherwise handle it, cover the applicable switch, frequency, parent-feature
  effects, and least-disruptive handling path.

Established MQ boundary:

- For MQ message streams such as Kafka or Pulsar with
  `enable-tidb-extension=true`, periodic `TIDB_WATERMARK` events are
  progress/control messages and may continue without DML. They are not
  business-row changes.
- There is no separate supported switch to disable only WATERMARK events and
  no supported option to reduce their emission frequency.
- Disabling `enable-tidb-extension` removes the complete TiDB extension
  payload, including `_tidb.commitTs` and watermark progress information. Do
  not present that as the default when consumers depend on extension fields.
- The least-disruptive MQ handling is for the consumer to ignore messages whose
  `type` is `TIDB_WATERMARK`.

Established Cloud Storage boundary:

- For Amazon S3, GCS, Azure Blob Storage, or NFS, do not claim that
  `TIDB_WATERMARK` is written inline into table data files such as `CDC*.json`.
  Generic Canal-JSON WATERMARK documentation does not establish physical
  placement in Cloud Storage files.
- Cloud Storage progress is represented by the top-level `{prefix}/metadata`
  object and its global `checkpoint-ts`: transactions with a smaller
  `commit-ts` have been written to downstream storage.
- Use this metadata checkpoint as the storage completeness barrier. Do not
  invent an inline `watermarkTs` record to compare with it.

When public documentation is ambiguous across sink types, preserve the
transport-specific established Support boundary and do not generalize from one
transport to another.