owner(ticdc): close the ddl sink to fix the resource leak#12678
owner(ticdc): close the ddl sink to fix the resource leak#126783AceShowHand wants to merge 1 commit into
Conversation
|
This cherry pick PR is for a release branch and has not yet been approved by triage owners. To merge this cherry pick:
DetailsInstructions 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
Bot
added
release-note
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request removes a noisy log statement in shared_client.go and updates ddl_sink.go to properly close the DDL sink before setting it to nil during retries. However, a potential data race and nil-pointer panic was identified in ddl_sink.go because s.sink is accessed and modified concurrently without synchronization; introducing a mutex is recommended to protect these operations.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| if s.sink != nil { | ||
| s.sink.Close() | ||
| s.sink = nil | ||
| log.Info("close the ddl sink, rebuild it when trying again", | ||
| zap.String("namespace", s.changefeedID.Namespace), zap.String("changefeed", s.changefeedID.ID)) | ||
| } |
There was a problem hiding this comment.
Potential Data Race and Nil-Pointer Panic on s.sink\n\nThere is a potential concurrency issue where s.sink is accessed and modified without proper synchronization:\n1. The Race: s.sink is read/written concurrently by the background loop (via retrySinkAction and makeSinkReady) and other goroutines (such as emitBootstrap which calls makeSinkReady and then s.sink.WriteDDLEvent).\n2. The Panic: If retrySinkAction encounters an error, it closes the sink and sets s.sink = nil (lines 178-179). If emitBootstrap is running concurrently, it might check that s.sink is not nil (or initialize it via makeSinkReady), but before it can call s.sink.WriteDDLEvent, retrySinkAction sets s.sink = nil, leading to a nil-pointer dereference and panic.\n\n### Recommendation\nIntroduce a mutex (e.g., sinkMu sync.Mutex) in ddlSinkImpl to protect all read, write, and close operations on s.sink across makeSinkReady, retrySinkAction, close, and emitBootstrap.
There was a problem hiding this comment.
we should fix the race condition thing with an atomic pointer in a separate PR, since this piece of code is just copied from master branch.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kennytm The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[LGTM Timeline notifier]Timeline:
|
2 participants
What problem does this PR solve?
Issue Number: ref #12666
What is changed and how it works?
Check List
Tests
Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note