-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
release-22.2: spanconfig: deflake spanconfigreconcilerccl/TestDataDriven #105061
release-22.2: spanconfig: deflake spanconfigreconcilerccl/TestDataDriven #105061
Conversation
e4d302b
to
35d3601
Compare
7731020
to
c838b7c
Compare
Thanks for opening a backport. Please check the backport criteria before merging:
If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.
Add a brief release justification to the body of your PR to justify this backport. Some other things to consider:
|
The test fixed in this PR fails on CI:
Likely the data-driven parser for this test on @irfansharif Could you take a look? |
c838b7c
to
0c3aaec
Compare
Fixes #98038. This test set up two protection records over two schema objects at two timestamps ts=3 and ts=4. /Table/10{6-7} protection_policies=[{ts: 3} {ts: 4}] /Table/10{7-8} protection_policies=[{ts: 3} {ts: 4}] When it later released those protection records: release record-id=3 release record-id=4 ---- It asserted that the span config mutations showed that we did infact get rid of the protected state: mutations ---- delete /Table/10{6-7} upsert /Table/10{6-7} range default delete /Table/10{7-8} upsert /Table/10{7-8} range default But since release of these protections was non-atomic, in #98038 we observed the following transition instead. delete /Table/10{6-7} upsert /Table/10{6-7} protection_policies=[{ts: 4}] delete /Table/10{7-8} upsert /Table/10{7-8} protection_policies=[{ts: 4}] delete /Table/10{6-7} upsert /Table/10{6-7} range default delete /Table/10{7-8} upsert /Table/10{7-8} range default That is, we first got rid of the record with ts=3 and only then got rid of ts=4. We just rewrite the test to assert on the final state of the records that show no remaining protections, instead of trying to add synchronization for mutations. Release note: None
0c3aaec
to
2078e33
Compare
(Rebased to pick up #105194.) |
Backport 1/1 commits from #98082 on behalf of @irfansharif.
/cc @cockroachdb/release
Fixes #98038. This test set up two protection records over two schema objects at two timestamps ts=3 and ts=4.
When it later released those protection records:
It asserted that the span config mutations showed that we did infact get rid of the protected state:
But since release of these protections was non-atomic, in #98038 we observed the following transition instead.
That is, we first got rid of the record with ts=3 and only then got rid of ts=4. We just rewrite the test to assert on the final state of the records that show no remaining protections, instead of trying to add synchronization for mutations.
Release note: None
Fixes #104858
Release justification: fixing a flaky test