# TiCDC Essential Detail Cluster ID

## Background and goal

The Essential TiCDC metadata Detail path calls Serverless
`ChangefeedOpsService.GetChangefeed`. Its request previously populated both
`cluster_id` and `changefeed_id` from the opaque changefeed ID. The Serverless
protobuf requires `cluster_id` to be the user TiDB cluster ID, so a valid
Essential Detail request could not reliably resolve its upstream changefeed.

This change makes the outgoing request use the canonical request cluster ID
and keeps the existing fail-closed response checks.

## Contract and implementation

- Convert the resolved numeric Clinic cluster ID to its decimal string form for
  `GetChangefeedRequest.ClusterId`.
- Continue to send the opaque path parameter as
  `GetChangefeedRequest.ChangefeedId`.
- Preserve the existing checks that the upstream response has both the
  requested changefeed ID and the requested source cluster ID; either mismatch
  returns the existing not-found result.
- Add an Essential Detail regression assertion for both outgoing request
  fields. Existing Essential List, Dedicated, and Dataflow-NG behavior is
  unchanged.

## Validation and delivery

Run focused TiCDC, handler, config, and router tests from the
`clinic_data_service` Go module, then build `cmd/api/main.go`. This modifies
the `clinic/data-service` image only.

Deploy through the dedicated Clinic Data Service CD workflow and the existing
`clinic-data-service` app-delivery application. No desired-state, Gateway, or
PrivateLink configuration changes are required. Validate Essential internal
Detail in staging, then Dedicated and NextGen Detail regression requests before
any separately authorized production release.