-
Type:
Task
-
Resolution: Won't Do
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Integration
- The server uses mongot-localdev, which serves both queries and index commands. We face a race condition created by the fact that in server's testing infra, the mongos must replicate all index commands to all mongods so they can forward to their coupled mongot.
- For normal collections, we run $listSearchIndexes on every mongod in a javascript library until its coupled mongot reports that the given search index is queryable. However, because these are views and the view catalog lives exclusively on the primary shard, mongos must resolve the view before we can call listSearchIndexes on the mongod.
- Thus additional work must be done to move the logic to wait for replication of an index command on all mongots from the search js library.
-
- This involves having DocumentSourceListSearchIndexes acquire the viewPipeline in retrieveCollectionUUIDAndResolveView
- DocumentSourceListSearchIndexes::doGetNext() calls `
search_index_testing_helper::_replicateSearchIndexCommandOnAllMongodsForTesting()` - change the response of shardSvrRunSearchIndexCommand to actually return the response from search index manager
- search_index_testing_helper::_replicateSearchIndexCommandOnAllMongodsForTesting() must iterate across the responses from the multicast and ensure that for a given host and port, the response indicates the index is queryable/ready AND that the "latestDefinition" field matches the definition from the index command mongos forwarded to the shards
-
- if a response indicates the index is not ready, search_index_testing_helper::_replicateSearchIndexCommandOnAllMongodsForTesting() must call $listSearchIndexes on that hostAndPort until the necessary conditions were met
- we should change jstests/libs/search.js to not call
runListSearchIndexHelper() for sharded clusters
- is depended on by
-
-
- In Code Review
-