-
Notifications
You must be signed in to change notification settings - Fork 165
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
RCORE-2209 Treat completing a client reset as receiving a MARK message #7921
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -53,9 +53,9 @@ bool MigrationStore::load_data(bool read_only) | |
|
||
auto tr = m_db->start_read(); | ||
// Start with a reader so it doesn't try to write until we are ready | ||
SyncMetadataSchemaVersionsReader schema_versions_reader(tr); | ||
SyncMetadataSchemaVersionsReader schema_versions_reader(*tr); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. All of the changes to migration store, pending bootstrap store, sync metadata schema, pending bootstrap store, and subscriptions are just secondary effects of making PendingResetStore::has_pending_reset() take a Group rather than a TransactionRef. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. aside from passing around a ref vs const ref to a shared_ptr, is there a reason why this changed from a Transaction to a Group? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Aside from passing around a const ref instead of a const ref to a shared_ptr, is there a reason the parameter is a Group now and not a Transaction? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. aside from passing around a ref vs ptr, is there a reason why this changed from a Transaction to a Group? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The root change is enabling |
||
if (auto schema_version = | ||
schema_versions_reader.get_version_for(tr, internal_schema_groups::c_flx_migration_store)) { | ||
schema_versions_reader.get_version_for(*tr, internal_schema_groups::c_flx_migration_store)) { | ||
if (*schema_version != c_schema_version) { | ||
throw RuntimeError(ErrorCodes::UnsupportedFileFormatVersion, | ||
"Invalid schema version for flexible sync migration store metadata"); | ||
|
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.
does this assume that if we make any upload progress that we'll have fully uploaded all changes and we know for sure we aren't going to get another client reset from any recovered changesets? maybe now that we have compensating writes that doesn't really matter as much?
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.
Uploading changesets should either result in the server acknowledging the upload or sending a client reset and not both, so once our UPLOAD is acked the window for getting a client reset due to those changesets being invalid has ended.
I think this check is probably wrong and it needs to actually be checking if we've reached the client version at the time of the client reset (or at time of opening).
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.
It took a while to figure out how to test it but this is indeed incorrect; it marks the client reset as complete as soon as any changesets are acked rather than when all of the recovered changesets are.