-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 6.0.0, 7.0.0, 8.0.0, 8.2.0-rc0, 8.1.0
-
Component/s: None
-
Catalog and Routing
-
ALL
-
-
None
-
3
-
TBD
-
🟦 Shard Catalog
-
None
-
None
-
None
-
None
-
None
-
None
If the listIndexes command is run over a timeseries collection with the includeIndexBuildInfo: true option, it will return a ok:1, but the response cursor will be empty, rather than containing all indexes as expected:
> db.createCollection("myts", {timeseries: {timeField: 't'}}); { "ok" : 1, ... } > db.myts.createIndex({t: 1}) { "ok" : 1, ... } > db.runCommand({listIndexes: "myts", includeIndexBuildInfo: true}) { "ok" : 1, "cursor" : { "firstBatch" : [ ], ... } ... }
Technically the cause is that listIndexes with includeIndexBuildInfo generates a different response format:
> db.runCommand({listIndexes: "system.buckets.myts"}) { "ok": 1, "cursor" : { "firstBatch" : [ { "v" : 2, ... } ], ... }, ...} > db.runCommand({listIndexes: "system.buckets.myts", includeIndexBuildInfo: true}) { "ok": 1, "cursor" : { "firstBatch" : [ { "spec" : { "v" : 2, ... } ], ... }, ...}
Yet the timeseries index translation logic is always expecting a response in the first format. If it is passed in a response in the second format, it will interpret is as an untranslatable index and silently remove it from the output.
A similar behavior happens when using includeBuildUUIDs: true and there is an in-progress index build.
In both cases listIndexes should either translate the index appropriately or return an NotImplemented error .