-
Notifications
You must be signed in to change notification settings - Fork 4k
mma: fix minor todos related to pending changes #157933
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
Conversation
|
It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR? 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
sumeerbhola
left a comment
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.
Only look at the second commit. The first commit is from #157930
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @tbg and @wenyihu6)
wenyihu6
left a comment
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.
Reviewable status:
complete! 1 of 0 LGTMs obtained (waiting on @tbg)
Some methods now take a PendingRangeChange as parameter, insted of a slice of pendingReplicaChanges, to make it clearer that these are changes for the same range. Also removed two todos: - The RangeID continues to be a field in pendingReplicaChange, since it is convenient (mainly for logging and testing), despite redundancy with the containing PendingRangeChange. This is because the contained relationship is not maintained in various maps keyed by the changeID. - The changes in a rangeState are not modeled as a PendingRangeChange since the concept is redundant -- they are already contained in a range specific container. Informs cockroachdb#157049 Epic: CRDB-55052 Release note: None
34b0d35 to
6a5f0d6
Compare
|
TFTR! Rebased on master. |
|
bors r=wenyihu6 |
157908: kvpb: add (*RangeFeedEvent).EventType method r=wenyihu6 a=stevendanna A small helper for printing the type of an event since this type is enum-like. Informs #135332 Release note: None 157933: mma: fix minor todos related to pending changes r=wenyihu6 a=sumeerbhola Some methods now take a PendingRangeChange as parameter, insted of a slice of pendingReplicaChanges, to make it clearer that these are changes for the same range. Also removed two todos: - The RangeID continues to be a field in pendingReplicaChange, since it is convenient (mainly for logging and testing), despite redundancy with the containing PendingRangeChange. This is because the contained relationship is not maintained in various maps keyed by the changeID. - The changes in a rangeState are not modeled as a PendingRangeChange since the concept is redundant -- they are already contained in a range specific container. Informs #157049 Epic: CRDB-55052 Release note: None 157953: release: released CockroachDB version v26.1.0-alpha.0. Next version: v26.1.0-alpha.1 r=celiala a=cockroach-teamcity Release note: None Epic: None Release justification: non-production (release infra) change. 157956: roachtest/vecindex: Always download datasets when testing r=mw5h a=mw5h Previously, the vecindex roachtest would use the vecann default of attempting to reuse cached dataset files. This led to a situation where a test runner apparently cached a truncated file, causing the test to fail repeatedly when run from that runner. This patch changes the behavior to always download the dataset, so the test doesn't repeatedly flake. Fixes: #157119 Release note: None Co-authored-by: Steven Danna <[email protected]> Co-authored-by: sumeerbhola <[email protected]> Co-authored-by: Justin Beaver <[email protected]> Co-authored-by: Matt White <[email protected]>
|
Build failed (retrying...): |
Some methods now take a PendingRangeChange as parameter, insted of a slice
of pendingReplicaChanges, to make it clearer that these are changes for
the same range.
Also removed two todos:
convenient (mainly for logging and testing), despite redundancy with the
containing PendingRangeChange. This is because the contained relationship
is not maintained in various maps keyed by the changeID.
the concept is redundant -- they are already contained in a range specific
container.
Informs #157049
Epic: CRDB-55052
Release note: None