Allow leaving corrupted indexes as readable after header repair#3801
Allow leaving corrupted indexes as readable after header repair#3801ScottDugas merged 19 commits intoFoundationDB:mainfrom
Conversation
In the case of a broader corruption, where records have been corrupted along with the store header, it may be beneficial to look at the indexes involved while looking at the store. This may be useful if you want to resurrect some information from the indexes if any exists.
…tBase As noted in the PR `withStore` was potentially brittle because of the `recordStore` field. I could have changed that to a consumer but still set the field, but that felt just as bad, so I changed it to extend FDBRecordStoreConcurrentTestBase.
Conflict on PreventCommitCheck because that was brought into main on a different PR. Conflict on FDBRecordStoreRepairHeaderTest because I added a method close to a method that was renamed. I changed the new test method because the rename made it clear that createOriginalRecords didn't create anything, and thus the call was unnecessary
Also, I had to fix a couple tests that dependended on the recordStore field.
Primarily by adding helper methods
This makes it easier to cover the version that doesn't take a parameter.
I'm not sure whether we should make the assertion stronger when we expect there to be data.
| @API(API.Status.DEPRECATED) | ||
| public CompletableFuture<NonnullPair<Boolean, FDBRecordStore>> repairMissingHeader(final int userVersion, FormatVersion minimumPossibleFormatVersion) { | ||
| return repairMissingHeader(userVersion, minimumPossibleFormatVersion, null); | ||
| } |
There was a problem hiding this comment.
I looked into this test gap:
I think I'm seeing a false test gap. https://fdb.teamscale.io/activity/merge-requests/foundationdb-fdb-record-layer/FoundationDB%2Ffdb-record-layer%2F3801 for commit 049a768 I checked the upload details, and downloaded the coverage, and all the repairMissingHeader methods have full method coverage: https://fdb.teamscale.io/project/project?name=foundationdb-fdb-record-layer&action=showExternalAnalysisUploads -- https://fdb.teamscale.io/api/projects/foundationdb-fdb-record-layer/external-analysis/reports/FORK_MR%2F3801%2FScottDugas%2Frepair-store-without-disable%3A1770831010000/0
Oh, I see, in the coverage provided it is at 5811:
<method name="repairMissingHeader" desc="(ILcom/apple/foundationdb/record/provider/foundationdb/FormatVersion;)Ljava/util/concurrent/CompletableFuture;" line="5811">
<counter type="INSTRUCTION" missed="0" covered="6"/>
<counter type="LINE" missed="0" covered="1"/>
<counter type="COMPLEXITY" missed="0" covered="1"/>
<counter type="METHOD" missed="0" covered="1"/>
</method>
And if I look at the html from jacoco, you can see that the line numbers are different:
There was a problem hiding this comment.
Seems like we're already doing this?
There was a problem hiding this comment.
Partially, I think the fact that IndexScrubbing only works for value indexes is still valuable.
| } | ||
|
|
||
| enum DisableIndexBehavior { | ||
| LeaveCorrupted { |
Instead of having a @nullable reason, this means using a method, which makes it a lot clearer what you are intending.
Most notably, adding a missing join() in the test code
1376463 to
4ad934c
Compare
In the case of a broader corruption, where records have been corrupted along with the store header, it may be beneficial to look at the indexes involved while looking at the store. This may be useful if you want to resurrect some information from the indexes if any exists.