logpuller: fix filterLoop flag propagation for stop tasks

[lidezhu]

What problem does this PR solve?

Issue Number: close #4261

What is changed and how it works?

This pull request addresses an issue related to filtering data loops in TiCDC, particularly in Bi-Directional Replication (BDR) scenarios. It introduces a filterLoop flag within the subscription mechanism to correctly identify and filter out data written by TiCDC itself, preventing infinite replication loops. The changes ensure that this critical filtering state is properly initialized and propagated across various internal components, enhancing the robustness of the replication process.

Highlights

• Added filterLoop field to subscribedSpan: A new boolean field filterLoop was added to the subscribedSpan struct. This field indicates whether to filter out values written by TiCDC itself, primarily for BDR (Bi-Directional Replication) mode.
• Propagated filterLoop in newSubscribedSpan: The newSubscribedSpan function was updated to accept a filterLoop parameter, ensuring that this value is correctly initialized when a new subscribedSpan is created.
• Ensured filterLoop consistency in tasks: The filterLoop value is now consistently passed through rangeTask and regionInfo structures, ensuring that the filtering logic is applied throughout the subscription lifecycle, especially when stopping tables.
• Updated unit tests: Existing unit tests were modified to accommodate the new filterLoop parameter in newSubscribedSpan calls, and a new test case TestStopTaskUsesSubscribedSpanFilterLoop was added to verify correct propagation of the filterLoop value when a table is stopped.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Questions

Will it cause performance regression or break compatibility?

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

Release note

Please refer to [Release Notes Language Style Guide](https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/release-notes-style-guide.html) to write a quality release note.

If you don't think this PR needs a release note then fill it with `None`.

Summary by CodeRabbit

• Improvements

  • Enhanced filtering logic for Bi-Directional Replication mode to better track TiCDC-generated values in subscription operations.

• Tests

  • Added test coverage to verify filtering behavior is correctly applied when managing subscribed table regions.

[gemini-code-assist]

Summary of Changes

Hello @lidezhu, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue related to filtering data loops in TiCDC, particularly in Bi-Directional Replication (BDR) scenarios. It introduces a filterLoop flag within the subscription mechanism to correctly identify and filter out data written by TiCDC itself, preventing infinite replication loops. The changes ensure that this critical filtering state is properly initialized and propagated across various internal components, enhancing the robustness of the replication process.

Highlights

• Added filterLoop field to subscribedSpan: A new boolean field filterLoop was added to the subscribedSpan struct. This field indicates whether to filter out values written by TiCDC itself, primarily for BDR (Bi-Directional Replication) mode.
• Propagated filterLoop in newSubscribedSpan: The newSubscribedSpan function was updated to accept a filterLoop parameter, ensuring that this value is correctly initialized when a new subscribedSpan is created.
• Ensured filterLoop consistency in tasks: The filterLoop value is now consistently passed through rangeTask and regionInfo structures, ensuring that the filtering logic is applied throughout the subscription lifecycle, especially when stopping tables.
• Updated unit tests: Existing unit tests were modified to accommodate the new filterLoop parameter in newSubscribedSpan calls, and a new test case TestStopTaskUsesSubscribedSpanFilterLoop was added to verify correct propagation of the filterLoop value when a table is stopped.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• logservice/logpuller/subscription_client.go
  • Added filterLoop field to the subscribedSpan struct.
  • Modified newSubscribedSpan function signature to accept a filterLoop boolean parameter.
  • Updated Subscribe method to pass the bdrMode value as filterLoop to newSubscribedSpan.
  • Changed rangeTask creation to use rt.filterLoop instead of bdrMode directly.
  • Modified regionInfo creation within setTableStopped to include rt.filterLoop.
• logservice/logpuller/subscription_client_test.go
  • Updated calls to newSubscribedSpan in TestGenerateResolveLockTask and TestResolveLockTaskDroppedWhenChannelFull to include the new filterLoop parameter.
  • Added a new test function TestStopTaskUsesSubscribedSpanFilterLoop to verify the correct propagation of the filterLoop value when a table is stopped.

Activity

• No human activity has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[coderabbitai]

📝 Walkthrough

Walkthrough

A new filterLoop flag is added to subscribedSpan to distinguish TiCDC-generated values in BDR mode. The flag is introduced as a constructor parameter, propagated through subscription initialization, and applied to region tasks when stopping tables.

Changes

Cohort / File(s)	Summary
filterLoop parameter propagation logservice/logpuller/subscription_client.go	Adds filterLoop boolean parameter to newSubscribedSpan constructor; stores flag on subscribedSpan; propagates value through rangeTask creation and region task enqueueing when stopping tables.
Test updates logservice/logpuller/subscription_client_test.go	Updates existing test calls to newSubscribedSpan with new filterLoop boolean argument; adds new TestStopTaskUsesSubscribedSpanFilterLoop test to verify region task enqueueing preserves filterLoop flag when stopping tables.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

Poem

🐰 A flag hops through the service neat,
To mark which spans the TiCDC beat,
Through rangeTask and region flows,
The filterLoop flag gently goes,
Distinguished values in BDR's light,
Now properly tagged—hoorah, all right!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title 'logpuller: fix filterLoop flag propagation for stop tasks' directly and specifically describes the main change: fixing how the filterLoop flag is propagated when stopping tasks.
Description check	✅ Passed	The pull request description is well-structured and addresses all major template sections with substantive content.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch ldz/fix-puller022402

---

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 and usage tips.}

[gemini-code-assist]

Code Review

This pull request correctly introduces a filterLoop flag to support Bidirectional Replication (BDR) mode, ensuring that events originating from TiCDC are not replicated back. The changes involve adding the filterLoop field to the subscribedSpan struct and propagating it to various tasks, which is a solid approach. A crucial bug fix in setTableStopped is included and well-covered by a new test.

My main suggestion is to refactor the rangeTask struct to remove a redundant filterLoop field, as this information is already available in the associated subscribedSpan. This will improve code clarity and maintainability. Overall, the changes are in the right direction.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: asddongmen, hongyunyan

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [asddongmen,hongyunyan]

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-02-25 03:50:27.609076436 +0000 UTC m=+240500.123871035: ☑️ agreed by hongyunyan.
• 2026-02-25 03:51:40.663231729 +0000 UTC m=+240573.178026348: ☑️ agreed by asddongmen.