The ShardingWriteRouter uses an option called 'allowLocks' during catalog cache refreshes which, when true, causes the refresh to exit rather than blocking if the refresh cannot be fulfilled with local information. However, though the allowLocks setting is sent to the getDatabase call and checked as part of the tassert, there is no early exit in place for the database section.
This means that the onInserts observer that uses the ShardingWriteRouter can end up blocking behind a catalog cache refresh.
This problem is also blocking the fix for SERVER-78115. This ticket is adding a majority write back into the SSCCL, and in the case that the ShardingWriteRouter triggers an DB refresh, the majority write ends up blocked because the onInserts is keeping an oplog hole open.
- causes
-
SERVER-80234 Catalog cache unit tests of allowLocks should block the refresh
- Closed
- is depended on by
-
SERVER-78115 Shard primaries must commit a majority write before using new routing information from the config server
- Closed