active-active: Fix tableInfo compatibility checks when enable-active-active is true#4181
Conversation
Summary of ChangesHello @hongyunyan, I'm Gemini Code Assist1! 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 refines the schema compatibility checking mechanism within the Highlights
🧠 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
Activity
Using Gemini Code AssistThe 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
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 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
|
📝 WalkthroughWalkthroughTable-mode compatibility checking in the dispatcher is tightened: compatibility is reset when a DDL event is processed and re-checked on subsequent DMLs or initial processing. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Code Review
This pull request refactors the logic for checking table schema compatibility with the replication mode, deferring checks from DDL events to subsequent DML events, and updates associated tests. However, a security audit identified two medium-severity issues in the BasicDispatcher compatibility checking logic: an unsafe type assertion that could lead to panics (Denial of Service) and a logic flaw allowing security checks to be bypassed after an initial failure. Additionally, there's a regression where DDL events are no longer validated for compatibility, potentially compromising data integrity in specialized replication modes. It is suggested to improve the robustness of the checkTableModeCompatibility function by using a type switch instead of a direct type assertion to mitigate these risks.
| } | ||
| return nil | ||
|
|
||
| return d.ensureTableModeCompatibility(event.(*commonEvent.DMLEvent).TableInfo) |
There was a problem hiding this comment.
The checkTableModeCompatibility method uses a direct type assertion event.(*commonEvent.DMLEvent) which is a regression and introduces a potential panic (Denial of Service) if called with a non-DML event. This unsafe assertion, combined with a defer block that sets tableModeCompatibilityChecked = true even on failure, creates a logic flaw allowing subsequent events to bypass security/integrity checks. This could lead to data inconsistency in active-active or soft-delete replication modes. It is recommended to use a type switch to safely handle event types and only set tableModeCompatibilityChecked = true if ensureTableModeCompatibility returns no error.
| return d.ensureTableModeCompatibility(event.(*commonEvent.DMLEvent).TableInfo) | |
| switch ev := event.(type) { | |
| case *commonEvent.DMLEvent: | |
| return d.ensureTableModeCompatibility(ev.TableInfo) | |
| default: | |
| log.Panic("checkTableModeCompatibility received unexpected event type", zap.Any("event", event)) | |
| return nil // Should be unreachable | |
| } |
| // reset the tableModeCompatibilityChecked when receive a ddl event, | ||
| // because ddl event may change the table schema, | ||
| // which may cause the table not compatible with current replication mode anymore. | ||
| d.tableModeCompatibilityChecked = false |
There was a problem hiding this comment.
The compatibility check for DDL events has been removed and replaced with a simple reset of the tableModeCompatibilityChecked flag. This change allows incompatible DDL queries (e.g., those dropping required columns for active-active mode) to be applied to the downstream database before any validation occurs. The check is now delayed until the next DML event arrives, which violates the principle of failing securely. Incompatible schema changes should be blocked before they are applied to prevent downstream corruption or replication loops.
Recommendation: Re-introduce the compatibility check for DDL events before they are applied to the downstream sink via DealWithBlockEvent.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: flowbehappy, lidezhu, wk989898 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 |
|
/retest |
What problem does this PR solve?
Issue Number: close #3446
What is changed and how it works?
This pull request refines the schema compatibility checking mechanism within the
BasicDispatcherfor active-active replication. It changes how DDL events interact with thetableModeCompatibilityCheckedflag, ensuring that schema compatibility is re-evaluated for DML events following any schema alterations. This prevents misconfigurations by guaranteeing that the most current table schema is always validated against the replication mode.Highlights
tableModeCompatibilityCheckedflag tofalseinstead of directly performing the compatibility check. This ensures that the schema is re-evaluated on the subsequent DML event.checkTableModeCompatibility: ThecheckTableModeCompatibilityfunction has been simplified to primarily handle DML events, as DDL events no longer directly invoke it for validation.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
Summary by CodeRabbit
Refactor
Tests
Chore