Upon implementing SERVER-108407, it was discovered that the 'listCollections' command that is run here (inside SearchIndexProcessRouter::fetchCollectionUUIDAndResolveView), while running the $listSearchIndexes aggregation stage (enters here) on a sharded collections topology (note not the sharded cluster topology where the collection is not sharded) on a viewless time-series collection returns the incorrect value of "collection" instead of "timeseries" for the "type" field.

Note that for both running the $listSearchIndex commands on other sharded toplogies (single shard and sharded cluster), and when running the other search index db commands (on all topologies) we get the correct value of "timeseries". So this issue is specific to the combination of:

• Running $listSearchIndexes aggregation stage
• On a sharded collections topology
• Against a viewless timeseries collection

The shard interface for the analogous logic appears to be returning the correct result of if the collection is a timeseries for all 4 operations ($listSearchIndexes, createSearchIndex, updateSearch, dropSearchIndex).

Note that all 4 of these operations use a common interface for search index operations defined here.

Its unclear if the search index logic is doing something incorrect in this case, or if its a CAR issue (or some combination of both). The assignee of this ticket will need to investigate the root cause deeper to see which team(s) need to patch this issue.

To begin investigating, start with the question, why on a sharded collection topology against a viewless time-series collection, does $listSearchIndex have different behavior w.r.t the 'listCollections' call to the search index commands (createSearchIndex, updateSearchIndex, dropSearchIndex)? Perhaps the fact that $listSearchIndexes and the search index commands have different remote rpc entry points on the router has something to do with it.