-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VReplication: Properly ignore errors from trying to drop tables that don't exist #16505
Conversation
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Tests
Documentation
New flags
If a workflow is added or modified:
Backward compatibility
|
Signed-off-by: Matt Lord <mattalord@gmail.com>
7b0e2a6
to
a5297e2
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #16505 +/- ##
==========================================
+ Coverage 68.64% 68.73% +0.09%
==========================================
Files 1552 1556 +4
Lines 199544 199707 +163
==========================================
+ Hits 136976 137275 +299
+ Misses 62568 62432 -136 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Matt Lord <mattalord@gmail.com>
Signed-off-by: Matt Lord <mattalord@gmail.com>
ts.Logger().Warningf("%s: Table %s did not exist when attempting to remove it", topoproto.TabletAliasString(source.GetPrimary().GetAlias()), tableName) | ||
return nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a separate bug fixed here that would have caused the Delete/Cancel to leave any yet to be removed tables orphaned on the source/target. We never got into this block due to the noted issues, however, so this bug could not be triggered before this PR and thus in effect did not exist. The unit test (and framework used) was also updated to test for this.
Signed-off-by: Matt Lord <mattalord@gmail.com>
Signed-off-by: Matt Lord <mattalord@gmail.com>
Thanks for the helpful review, @rohit-nayak-ps ! Just FYI, as I know that you're working on more unit tests for the workflow package, I added support for testing query error handling w/o a real mysqld instance here: 7ce084b |
Signed-off-by: Matt Lord <mattalord@gmail.com>
Signed-off-by: Matt Lord <mattalord@gmail.com>
…don't exist (#16505) Signed-off-by: Matt Lord <mattalord@gmail.com>
…don't exist (vitessio#16505) Signed-off-by: Matt Lord <mattalord@gmail.com>
Description
This is a follow-up to: #15977 We should backport the fix to v20, where that work was first added.
There were two problems:
status.Error
and NOT thesqlerror.SQLError
type returned from the database failure so we needed to first convert itError number: 1051; Symbol: [ER_BAD_TABLE_ERROR]
This was missed due to inadequate testing. I've added an endtoend test here — along with updating the unit test (and framework) to test this behavior — which fails on main as expected:
The updated unit test demonstrating that we are properly handling the case where 1 of N tables doesn't exist:
And which fails, as expected, on main:
Related Issue(s)
Checklist