SERVER-48783 Critical section should not be entered when performing a shard version recovery

3 files changed, 8 insertions, 12 deletions

diff --git a/src/mongo/db/s/collection_sharding_runtime.cpp b/src/mongo/db/s/collection_sharding_runtime.cpp
index 6c468ddff0f..cb8ad8e1b32 100644
--- a/src/mongo/db/s/collection_sharding_runtime.cpp
+++ b/src/mongo/db/s/collection_sharding_runtime.cpp
@@ -167,12 +167,10 @@ void CollectionShardingRuntime::checkShardVersionOrThrow(OperationContext* opCtx
 }
 
 void CollectionShardingRuntime::enterCriticalSectionCatchUpPhase(const CSRLock&) {
-    invariant(!_shardVersionInRecoverOrRefresh);
     _critSec.enterCriticalSectionCatchUpPhase();
 }
 
 void CollectionShardingRuntime::enterCriticalSectionCommitPhase(const CSRLock&) {
-    invariant(!_shardVersionInRecoverOrRefresh);
     _critSec.enterCriticalSectionCommitPhase();
 }
 
diff --git a/src/mongo/db/s/collection_sharding_runtime.h b/src/mongo/db/s/collection_sharding_runtime.h
index 7135212fd2b..7224dacce4f 100644
--- a/src/mongo/db/s/collection_sharding_runtime.h
+++ b/src/mongo/db/s/collection_sharding_runtime.h
@@ -120,8 +120,6 @@ public:
      * with both the collection lock and CSRLock held in exclusive mode.
      *
      * In these methods, the CSRLock ensures concurrent access to the critical section.
-     *
-     * The shardVersionRecoverRefresh future must be boost::none when invoking these methods.
      */
     void enterCriticalSectionCatchUpPhase(const CSRLock&);
     void enterCriticalSectionCommitPhase(const CSRLock&);
@@ -286,6 +284,14 @@ private:
 
 /**
  * RAII-style class, which obtains a reference to the critical section for the specified collection.
+ *
+ * Shard version recovery/refresh procedures always wait for the critical section to be released in
+ * order to get the latest shard version.
+ *
+ * However, the critical section can be entered while a recovery/refresh is ongoing because the
+ * shard version obtained from the config server is casually consistent in respect to incoming
+ * opertions (still relying on the current shard version).
+ *
  */
 class CollectionCriticalSection {
     CollectionCriticalSection(const CollectionCriticalSection&) = delete;
diff --git a/src/mongo/db/s/shard_filtering_metadata_refresh.cpp b/src/mongo/db/s/shard_filtering_metadata_refresh.cpp
index 47e5a3835f1..18e1b8da13b 100644
--- a/src/mongo/db/s/shard_filtering_metadata_refresh.cpp
+++ b/src/mongo/db/s/shard_filtering_metadata_refresh.cpp
@@ -102,9 +102,6 @@ SharedSemiFuture<void> recoverRefreshShardVersion(ServiceContext* serviceContext
                 auto* const csr = CollectionShardingRuntime::get(opCtx.get(), nss);
                 auto csrLock = CollectionShardingRuntime::CSRLock::lockExclusive(opCtx.get(), csr);
                 csr->resetShardVersionRecoverRefreshFuture(csrLock);
-                if (runRecover) {
-                    csr->exitCriticalSection(opCtx.get());
-                }
             });
 
             if (runRecover) {
@@ -194,11 +191,6 @@ void onShardVersionMismatch(OperationContext* opCtx,
                     csr->getCriticalSectionSignal(opCtx, ShardingMigrationCriticalSection::kWrite);
 
                 if (!inRecoverOrRefresh && !critSecSignal) {
-                    if (runRecover) {
-                        CollectionShardingRuntime::get(opCtx, nss)
-                            ->enterCriticalSectionCatchUpPhase(csrLock);
-                    }
-
                     csr->setShardVersionRecoverRefreshFuture(
                         recoverRefreshShardVersion(opCtx->getServiceContext(), nss, runRecover),
                         csrLock);