api(ticdc): return task_status for changefeeds in warning state

[shreyasp-db]

What problem does this PR solve?

Issue Number: close #12793

The changefeed query/detail OpenAPI endpoints normally return task_status, e.g. (as seen via cdc cli changefeed query -c <CHANGEFEED_ID>, which is just one client of this API):

"task_status": [
  {
    "capture_id": "d4ecb27f-bb40-4655-bf72-192852e4ef80",
    "table_ids": [3508, 3520, 3523, 3529, 3531]
  }
]

However, when a changefeed is in the warning state, task_status is not returned — which is often exactly when this per-capture table assignment is most needed for debugging. This affects every caller of the query API (the GET /api/v1/changefeeds/{id}, GET /api/v2/changefeeds/{id}, and meta-info endpoints), not just the cdc cli.

The changefeed detail handlers gate the task_status population on an exact info.State == model.StateNormal check, so GetAllTaskStatuses is skipped for any other state, including warning.

What is changed and how it works?

A changefeed in the warning state is still running (its processors are active), so its task statuses remain meaningful. FeedState.IsRunning() already encodes this exact semantic (StateNormal || StateWarning).

This PR replaces the exact StateNormal check with
FeedState.IsRunning() in the three changefeed-detail handlers:

• cdc/api/v1/api.go — getChangefeed
• cdc/api/v2/changefeed.go — getChangeFeed
• cdc/api/v2/changefeed.go — getChangeFeedMetaInfo

Check List

Tests

• Unit test

Extended TestGetChangeFeed (cdc/api/v2) with a table-driven check asserting task_status is returned for normal and warning states and omitted for stopped.

Questions

Will it cause performance regression or break compatibility?

No. It adds one GetAllTaskStatuses call for changefeeds in the warning state (the same call already made for normal), and only widens the set of states for which task_status is populated — no field or format changes.

Do you need to update user documentation, design documentation or monitoring documentation?

No.

Release note

Fix the changefeed query API not returning `task_status` for changefeeds in the warning state.

Summary by CodeRabbit

• Bug Fixes
  • Changefeed details now include task status across all running states, including warning states.
  • Temporary task-status retrieval failures no longer prevent changefeed details from loading.
  • Stopped changefeeds correctly omit task-status information.

[ti-chi-bot]

Welcome @shreyasp-db!

It looks like this is your first PR to pingcap/tiflow 🎉.

I'm the bot to help you request reviewers, add labels and more, See available commands.

We want to make sure your contribution gets all the attention it needs!



Thank you, and welcome to pingcap/tiflow. 😃

[ti-chi-bot]

Hi @shreyasp-db. Thanks for your PR.

I'm waiting for a pingcap member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[pingcap-cla-assistant]

All committers have signed the CLA.

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

[dveeden]

/ok-to-test

[ekexium]

LGTM. Please file an issue and link the PR to it

[ti-chi-bot]

@ekexium: adding LGTM is restricted to approvers and reviewers in OWNERS files.

Details

In response to this:

LGTM. Please file an issue and link the PR to it

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 3AceShowHand, ekexium, hongyunyan
Once this PR has been reviewed and has the lgtm label, please assign yudongusa for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS [3AceShowHand,hongyunyan]
• cdc/api/v2/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2026-08-03 11:18:47.659740925 +0000 UTC m=+2440513.695835981: ☑️ agreed by 3AceShowHand.
• 2026-08-03 11:52:51.92893628 +0000 UTC m=+2442557.965031366: ☑️ agreed by hongyunyan.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b5fbd14-89c8-4966-90d1-f66bc0c03c6e

📥 Commits

Reviewing files that changed from the base of the PR and between f681fdf and d8d0325.

📒 Files selected for processing (3)

• cdc/api/v1/api.go
• cdc/api/v2/changefeed.go
• cdc/api/v2/changefeed_test.go

---

📝 Walkthrough

Walkthrough

Changefeed APIs now collect task statuses for all running states, including warning states. Task-status retrieval failures are logged while changefeed responses continue without task-status data. Tests cover normal, warning, and stopped feed responses.

Changes

Changefeed task-status handling

Layer / File(s)	Summary
Running-state task-status flow and validation cdc/api/v1/api.go, cdc/api/v2/changefeed.go, cdc/api/v2/changefeed_test.go	Version 1 and version 2 endpoints collect task statuses for all running states. Retrieval failures are logged, and responses continue without task-status data. Tests validate normal and warning task statuses and stopped-feed omission.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: asddongmen

Poem

A rabbit checks each running stream,
Warning states now join the team.
If task notes fail to hop in sight,
The feed still returns clean and right.
Stopped feeds leave no tracks behind.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description covers the problem, implementation, tests, compatibility, documentation, and release note, but it lacks the required linked issue.	Replace “Issue Number: none” with a linked issue using “close” or “ref”, such as “Issue Number: close #123”.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the API change that returns task_status for warning-state changefeeds.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.12.2)

Error: can't load config: unsupported version of the configuration: "" See https://golangci-lint.run/docs/product/migration-guide for migration instructions
The command is terminated due to an error: can't load config: unsupported version of the configuration: "" See https://golangci-lint.run/docs/product/migration-guide for migration instructions

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ekexium]

/check-issue-triage-complete

[nightowl-bot]

Core change looks good: FeedState.IsRunning() is the right predicate for including task_status in warning state. One thing to clarify before merge: the latest commit also makes GetAllTaskStatuses best-effort, changing the API from returning an error to returning 200 without task_status when task-status lookup fails. If that is intentional, please add a focused test for that error path. It would also be good to add coverage for the v1 and meta-info handlers, or extract the duplicated task-status collection into a helper so the running-state behavior is tested once. Finally, for the stopped case, consider asserting the raw JSON omits task_status, since the PR description says it is omitted.