Throttler: fix to client usage in vreplication and table GC #7422
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
In #7364 we introduced client.go, a throttler client, which we then used in tabletserver/tablegc, vreplication/engine and vstreamer/engine.
In the first two, I used the wrong check type:
ThrottleCheckSelf
, where in fact I should have usedThrottleCheckPrimaryWrite
because table GC and vreplication/engine both write to a primary and should therefore consider replication lag on the shard. This must have been a copy+paste mistake.The reason endtoend tests didn't catch this is that we don't have the capacity to run replicas on our vreplication tests, and so we only have primaries; in that scenario both types of checks converge to the same result.
Related Issue(s)
Tracking: #7362
Checklist
Impacted Areas in Vitess
Components that this PR will affect: