Skip to content
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-1872 Sync client should allow server bootstrapping at any time #7440

Merged
merged 71 commits into from
Jun 11, 2024
Merged
Show file tree
Hide file tree
Changes from 26 commits
Commits
Show all changes
71 commits
Select commit Hold shift + click to select a range
d09e4a3
First round of changes for server-initiated bootstraps
Mar 27, 2024
ae2574e
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 3, 2024
43391ca
Added test for role change bootstraps
Apr 10, 2024
35b1483
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 10, 2024
3424431
Updated test for handle role bootstraps
Apr 11, 2024
e0d6ac1
Updated baas/baasaas to use branch with fixes
Apr 11, 2024
f3eb7e0
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 11, 2024
7356ba2
updated changelog
Apr 11, 2024
9e32480
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 12, 2024
4431985
Updated test to verify bootstrap actually occurred
Apr 12, 2024
b87bc65
Fixed tsan warning
Apr 12, 2024
8447461
Move instead of copy
Apr 12, 2024
75a1d13
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 15, 2024
44d8e12
Updates from review; added comments to clarify bootstrap detection logic
Apr 15, 2024
944fb30
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 19, 2024
a9807d3
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 26, 2024
c0b1a49
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 27, 2024
60cb61e
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 27, 2024
37acf98
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 30, 2024
8d9557d
Updates from review
Apr 30, 2024
400aeba
Reworked test to fix msvc failure
Apr 30, 2024
4924597
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Apr 30, 2024
5ea89e2
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
May 2, 2024
3ad02b6
Reverted baas branch to master and protocol version to 12
May 2, 2024
06bdc01
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
May 2, 2024
3198ebd
Added comments to changes needed when merging to master; update baas …
May 3, 2024
7902db0
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
May 10, 2024
fe86341
Merging in recommended changes
May 14, 2024
7a5269b
Pulled over changes from other branch and tweaking download params
May 16, 2024
0a26a71
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
May 16, 2024
c7a4739
Refactored tests to validate different bootstrap types
May 17, 2024
2355dd9
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
May 17, 2024
509c97b
Address test failures
May 17, 2024
8a00447
Updated tests to get passing using the server params
May 20, 2024
b7b7180
Updated debug statements role change tests
May 21, 2024
484f526
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
May 21, 2024
f29542b
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
May 24, 2024
4f09342
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
May 28, 2024
3c193ec
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
May 30, 2024
4a4f13f
Updated to support new batch_state protocol changes; updated tests
Jun 3, 2024
a497259
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 3, 2024
8ecfe34
Updated role change tests and merged test from separate PR
Jun 4, 2024
f1d9425
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 4, 2024
e375bfd
Fixed issue with flx query verion 0 not being treated as a bootstrap
Jun 4, 2024
c4f0344
Cleaned up the tests a bit and reworked query version 0 handling
Jun 4, 2024
2aa76d9
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 4, 2024
39af9d6
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 4, 2024
165a651
Added TODO to query 0 bootstrap detection
Jun 4, 2024
a72e158
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 4, 2024
b850cac
Updates from review; updated batch_state for schema bootstraps
Jun 5, 2024
e2cd353
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 5, 2024
9c7b7af
Removed extra mutex in favor of state machine's mutex
Jun 5, 2024
2fcdbec
Increased timeout when waiting for app initial sync to complete
Jun 5, 2024
83d2a5c
Updated role change test to use test commands
Jun 6, 2024
5f2a7e1
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 6, 2024
51b54eb
Fixed lint warning
Jun 6, 2024
93386d4
Update resume and ident message handling
Jun 6, 2024
7e2c5a7
Updated future waits for the pause/resume test command
Jun 6, 2024
b2fcf51
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 6, 2024
239d162
Added session connected event for when session multiplexing is disabled
Jun 7, 2024
841f1d8
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 7, 2024
0f00b92
Updates from review; updated baas commit to include timing fix
Jun 7, 2024
1ffddd0
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 7, 2024
04624e9
Removed todo comment
Jun 7, 2024
84a4c23
Added wait_until() to state machine to wait for callback; updated rol…
Jun 7, 2024
3e97840
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 7, 2024
c4e6a9e
Updates from review
Jun 7, 2024
3649284
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 7, 2024
aede51b
Updated changelog after release
Jun 7, 2024
0d55022
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 10, 2024
a40bafc
Merge branch 'feature/role-change' of github.com:realm/realm-core int…
Jun 11, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

### Enhancements
* <New feature description> (PR [#????](https://github.com/realm/realm-core/pull/????))
* None.
* Add support for server initiated bootstraps. ([PR #7440](https://github.com/realm/realm-core/pull/7440))

### Fixed
* <How do the end-user experience this issue? what was the impact?> ([#????](https://github.com/realm/realm-core/issues/????), since v?.?.?)
Expand Down
7 changes: 4 additions & 3 deletions dependencies.yml
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@ PACKAGE_NAME: realm-core
VERSION: 14.6.2
OPENSSL_VERSION: 3.2.0
ZLIB_VERSION: 1.2.13
# https://github.com/10gen/baas/commits
# 5138f5c is 2024 Apr 19
BAAS_VERSION: 5138f5c924f9f376d31cbc2b1819e1d934600277
# TODO: Remove when switching to use Protocol version in RCORE-1972 and merging to master
# 51d0e54 is BAAS-30091 - 2024 May 01
BAAS_VERSION: 51d0e5411b9dab52cb24977d470c2c910d1b18c8
BAAS_VERSION_TYPE: githash
3 changes: 2 additions & 1 deletion evergreen/config.yml
Original file line number Diff line number Diff line change
Expand Up @@ -234,8 +234,9 @@ functions:
shell: bash
env:
BAASAAS_API_KEY: "${baasaas_api_key}"
# BAAS_VERSION and VERSION_TYPE are set by realm-core/dependencies.yml
BAASAAS_REF_SPEC: "${BAAS_VERSION}"
BAASAAS_START_MODE: "githash"
BAASAAS_START_MODE: "${BAAS_VERSION_TYPE|githash}"
script: |-
set -o errexit
set -o verbose
Expand Down
19 changes: 19 additions & 0 deletions src/realm/object-store/sync/sync_session.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,8 @@
#include <realm/sync/noinst/sync_schema_migration.hpp>
#include <realm/sync/protocol.hpp>

#include <ostream>

using namespace realm;
using namespace realm::_impl;

Expand All @@ -47,6 +49,23 @@ using SessionWaiterPointer = void (sync::Session::*)(util::UniqueFunction<void(s
constexpr const char SyncError::c_original_file_path_key[];
constexpr const char SyncError::c_recovery_file_path_key[];

namespace realm {

std::ostream& operator<<(std::ostream& out, const SyncSession::ConnectionState& val)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it doesn't look like this is used anywhere. do we need it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, probably not - this was left over from when I was using the connection state to detect the reconnect, but that has been replaced by the error check in event hook. I'll remove it.

{
switch (val) {
case SyncSession::ConnectionState::Disconnected:
return out << "DISCONNECTED";
case SyncSession::ConnectionState::Connecting:
return out << "CONNECTING";
case SyncSession::ConnectionState::Connected:
return out << "CONNECTED";
}
return out << "UNKNOWN";
}

} // namespace realm

/// STATES:
///
/// WAITING_FOR_ACCESS_TOKEN: a request has been initiated to ask
Expand Down
5 changes: 4 additions & 1 deletion src/realm/object-store/sync/sync_session.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -29,9 +29,10 @@
#include <realm/util/future.hpp>
#include <realm/version_id.hpp>

#include <iosfwd>
#include <map>
#include <mutex>
#include <unordered_map>
#include <map>

namespace realm {
class DB;
Expand Down Expand Up @@ -536,6 +537,8 @@ class SyncSession : public std::enable_shared_from_this<SyncSession> {
bool m_schema_migration_in_progress GUARDED_BY(m_state_mutex) = false;
};

std::ostream& operator<<(std::ostream& out, const SyncSession::ConnectionState& val);

} // namespace realm

#endif // REALM_OS_SYNC_SESSION_HPP
55 changes: 40 additions & 15 deletions src/realm/sync/client.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -839,12 +839,8 @@ void SessionImpl::update_subscription_version_info()
bool SessionImpl::process_flx_bootstrap_message(const SyncProgress& progress, DownloadBatchState batch_state,
int64_t query_version, const ReceivedChangesets& received_changesets)
{
// Ignore the call if the session is not active
if (m_state != State::Active) {
return false;
}

if (is_steady_state_download_message(batch_state, query_version)) {
// Ignore the message if the session is not active or a steady state message
if (m_state != State::Active || batch_state == DownloadBatchState::SteadyState) {
return false;
}

Expand Down Expand Up @@ -1103,24 +1099,53 @@ SyncClientHookAction SessionImpl::call_debug_hook(SyncClientHookEvent event, con
return call_debug_hook(data);
}

bool SessionImpl::is_steady_state_download_message(DownloadBatchState batch_state, int64_t query_version)
bool SessionImpl::is_steady_state_download_message(DownloadBatchState batch_state, int64_t query_version,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty convoluted. I have an approach bellow where this method should not be needed at all anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jbreams had some suggestions on a separate commit that reworked this function and the tracking of the changeset remote versions. This has been integrated into this PR and the tests have been updated to validate the different paths depending on how the changeset looks.

bool same_remote_versions)
{
// Should never be called if session is not active
REALM_ASSERT_EX(m_state == State::Active, m_state);
if (batch_state == DownloadBatchState::SteadyState) {
return true;
// Query version should always be the same or increasing
REALM_ASSERT_3(query_version, >=, m_wrapper.m_flx_active_version);

// Return early if already steady state or PBS (doesn't use bootstraps)
if (batch_state == DownloadBatchState::SteadyState || !m_is_flx_sync_session) {
return true; // Steady state
}

if (!m_is_flx_sync_session) {
return true;
// Bootstrap messages (i.e. non-steady state) are identified by:
// * DownloadBatchState of MoreToCome
// * DownloadBatchState of LastInBatch, and
// * first LastInBatch=true after one or more MoreToCome messages
// * query_version greater than the active query_version
// * LastInBatch=true message has 2 or more changesets and all have the same
// remote_version

// LastInBatch=False messages are always a bootstrap message
if (batch_state == DownloadBatchState::MoreToCome) {
return false; // Not steady state
}

// If this is a steady state DOWNLOAD, no need for special handling.
if (batch_state == DownloadBatchState::LastInBatch && query_version == m_wrapper.m_flx_active_version) {
return true;
// Messages with query_version greater than the active version are always a
// bootstrap message
if (query_version > m_wrapper.m_flx_active_version) {
return false; // Not steady state
}

// If this is the first LastInBatch=true message after one or more
// LastInBatch=false messages, this is the end of a bootstrap
if (m_last_download_batch_state == DownloadBatchState::MoreToCome) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i wish we didn't have to add this state tracking, but I think I see why we need it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - it's so we can catch the LastInBatch=false => LastInBatch=true sequence for the server initiated bootstraps. Can you think of a better way?

return false; // Not steady state
}

// Otherwise, if this is a LastInBatch=true message whose query version matches
// the current active version and all the changesets in the message have the
// same remote version, then this is a server initiated single message bootstrap
if (same_remote_versions) {
return false; // Not steady state
}

return false;
// If none of the previous checks were successful, then this is a steady state msg
return true; // Steady state
}

void SessionImpl::init_progress_handler()
Expand Down
41 changes: 31 additions & 10 deletions src/realm/sync/noinst/client_impl_base.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -1891,7 +1891,7 @@ void Session::send_bind_message()
session_ident_type session_ident = m_ident;
bool need_client_file_ident = !have_client_file_ident();
const bool is_subserver = false;

m_last_download_batch_state = DownloadBatchState::SteadyState;

ClientProtocol& protocol = m_conn.get_client_protocol();
int protocol_version = m_conn.get_negotiated_protocol_version();
Expand Down Expand Up @@ -2373,8 +2373,6 @@ Status Session::receive_download_message(const DownloadMessage& message)
// If this is a PBS connection, then every download message is its own complete batch.
bool last_in_batch = is_flx ? *message.last_in_batch : true;
auto batch_state = last_in_batch ? sync::DownloadBatchState::LastInBatch : sync::DownloadBatchState::MoreToCome;
if (is_steady_state_download_message(batch_state, query_version))
batch_state = DownloadBatchState::SteadyState;

auto&& progress = message.progress;
if (is_flx) {
Expand Down Expand Up @@ -2414,21 +2412,39 @@ Status Session::receive_download_message(const DownloadMessage& message)
return status;
}

version_type server_version = m_progress.download.server_version;
// Start with the download server version from the last download message, since the changesets in the new
// download message must have a remote version greater than (or equal to for FLX) this value.
version_type last_remote_version = m_progress.download.server_version;
version_type last_integrated_client_version = m_progress.download.last_integrated_client_version;
// If there are 2 or more changesets in this message, track whether or not the changesets all have the same
// download_server_version to help with determining if this is a single message server-initiated bootstrap or not.
bool same_remote_version = last_in_batch && message.changesets.size() > 1;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if last_in_batch is false, then same_remote_version is false too and its value never changes. This is incorrect for multi-message bootstraps (where you rely on batch_state). I think this value should always reflect the reality.

On another note, computing same_remote_version seems over-complicated. I think something like this should work:
bool bootstrap_in_progress = !last_in_batch || last_remote_version == progress.download.server_version || (message.changesets.size() > 1 && message.changesets.front().remote_version == message.changesets.back().remote_version)

where last_remote_version = progress.download.server_version once the message is processed (and initialized with m_progress.download.server_version).
You could add the check for query version too and get rid off is_steady_state_download_message completely.

bool after_first_changeset = false;

for (const RemoteChangeset& changeset : message.changesets) {
// Check that per-changeset server version is strictly increasing, except in FLX sync where the server
// version must be increasing, but can stay the same during bootstraps.
bool good_server_version = m_is_flx_sync_session ? (changeset.remote_version >= server_version)
: (changeset.remote_version > server_version);
// Check that per-changeset server version is strictly increasing since the last download server version,
// except in FLX sync where the server version must be increasing, but can stay the same during bootstraps.
bool good_server_version = m_is_flx_sync_session ? (changeset.remote_version >= last_remote_version)
: (changeset.remote_version > last_remote_version);
// Each server version cannot be greater than the one in the header of the download message.
good_server_version = good_server_version && (changeset.remote_version <= progress.download.server_version);
if (!good_server_version) {
return {ErrorCodes::SyncProtocolInvariantFailed,
util::format("Bad server version in changeset header (DOWNLOAD) (%1, %2, %3)",
changeset.remote_version, server_version, progress.download.server_version)};
changeset.remote_version, last_remote_version, progress.download.server_version)};
}
// Check to see if all the changesets in this LastInBatch=true message have the same remote_version
// If so, this is a server-initiated single message bootstrap
if (same_remote_version && after_first_changeset) {
Copy link
Collaborator

@danieltabacaru danieltabacaru May 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you decide to go with the current approach, then the following is enough:
bool same_remote_version = last_in_batch && message.changesets.size() > 1 && message.changesets.front().remote_version == message.changesets.back().remote_version

// After the first changeset compare the previous changeset's server version to the current changeset
// server version. If they are different then this is definitely not a bootstrap message
same_remote_version = changeset.remote_version == last_remote_version;
}
server_version = changeset.remote_version;
// Skip the first changeset, since `server_version` contains the incorrect value for this check
after_first_changeset = true;
// Save the remote version for the current changeset to compare against the next changeset
last_remote_version = changeset.remote_version;

// Check that per-changeset last integrated client version is "weakly"
// increasing.
bool good_client_version =
Expand All @@ -2453,6 +2469,11 @@ Status Session::receive_download_message(const DownloadMessage& message)
}
}

if (is_steady_state_download_message(batch_state, query_version, same_remote_version)) {
batch_state = DownloadBatchState::SteadyState;
}
m_last_download_batch_state = batch_state;

auto hook_action = call_debug_hook(SyncClientHookEvent::DownloadMessageReceived, progress, query_version,
batch_state, message.changesets.size());
if (hook_action == SyncClientHookAction::EarlyReturn) {
Expand Down
7 changes: 6 additions & 1 deletion src/realm/sync/noinst/client_impl_base.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -1133,6 +1133,10 @@ class ClientImpl::Session {
// the detection of download completion.
request_ident_type m_last_triggering_download_mark = 0;

// Keep track of the DownloadBatchState for the last download message to help
// determine if the current LastInBatch came after a message with MoreToCome.
DownloadBatchState m_last_download_batch_state = DownloadBatchState::SteadyState;
Copy link
Collaborator

@danieltabacaru danieltabacaru May 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is to distinguish between a LastInBatch meant as last message in a bootstrap and the one meant as SteadyState right? Can't the server send a third value for SteadyState? this would help with the one message bootstrap too and also simplify all the checks we currently do on the client.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish they would do that, too - but they rejected the request when I asked towards the beginning of the project :(

Copy link

@mpobrien mpobrien May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't recall that coming up, or any specific reason that would have been unreasonable - do you remember any more context around that convo? It might have just gotten some pushback since it would require a protocol bump and those are always a bit of extra work, but I don't see a strict technical reason why it couldn't be done.

Don't know if it makes sense at this point in the project, but we probably could add this on the server (unless I'm overlooking a concrete reason why we shouldn't) if it would provide a significant improvement here.


SessionWrapper& m_wrapper;

request_ident_type m_last_pending_test_command_ident = 0;
Expand Down Expand Up @@ -1197,7 +1201,8 @@ class ClientImpl::Session {
SyncClientHookAction call_debug_hook(SyncClientHookEvent event, const ProtocolErrorInfo&);
SyncClientHookAction call_debug_hook(const SyncClientHookData& data);

bool is_steady_state_download_message(DownloadBatchState batch_state, int64_t query_version);
bool is_steady_state_download_message(DownloadBatchState batch_state, int64_t query_version,
bool same_remote_versions);

void init_progress_handler();
void enable_progress_notifications();
Expand Down
14 changes: 9 additions & 5 deletions src/realm/sync/noinst/pending_bootstrap_store.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -169,6 +169,7 @@ void PendingBootstrapStore::add_batch(int64_t query_version, util::Optional<Sync
BinaryData compressed_data(compressed_changesets[idx].data(), compressed_changesets[idx].size());
cur_changeset.set(m_changeset_data, compressed_data);
}
size_t total_changesets = changesets_list.size();

tr->commit();

Expand All @@ -177,15 +178,18 @@ void PendingBootstrapStore::add_batch(int64_t query_version, util::Optional<Sync
}

if (did_create) {
m_logger.debug(util::LogCategory::changeset, "Created new pending bootstrap object for query version %1",
query_version);
m_logger.debug(util::LogCategory::changeset,
"Created new pending bootstrap object with %1 changesets for query version %2",
total_changesets, query_version);
}
else {
m_logger.debug(util::LogCategory::changeset, "Added batch to pending bootstrap object for query version %1",
query_version);
m_logger.debug(util::LogCategory::changeset,
"Added batch of %1 changesets (%2 total) to pending bootstrap object for query version %3",
changesets.size(), total_changesets, query_version);
}
if (progress) {
m_logger.debug(util::LogCategory::changeset, "Finalized pending bootstrap object for query version %1",
m_logger.debug(util::LogCategory::changeset,
"Finalized pending bootstrap object with %1 changesets for query version %2", total_changesets,
query_version);
}
m_has_pending = true;
Expand Down
5 changes: 5 additions & 0 deletions src/realm/sync/protocol.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,11 @@ namespace sync {
// Server replaces 'downloadable_bytes' (which was always zero prior this version)
// with an estimated progress value (double from 0.0 to 1.0) for flx sessions
//
// 13 Support for syncing collections (lists and dictionaries) in Mixed columns
Copy link
Collaborator

@danieltabacaru danieltabacaru May 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems it's going to be the other way around. Edit: not sure anymore 😅

//
// 14 Support for server initiated bootstraps, including bootstraps for role/
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you need to update get_current_protocol_version() to return the new version

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was waiting until this feature was about to be merged, but it really doesn't matter, since I'm using a feature branch and the feature is behind a feature flag.

// permissions changes instead of performing a client reset when changed.
//
// XX Changes:
// - TBD
//
Expand Down
Loading
Loading