Explaining a find fails over viewless timeseries collections on a sharded cluster

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.2.0-rc0
    • Affects Version/s: 8.2.0-rc0
    • Component/s: None
    • None
    • Catalog and Routing
    • ALL
    • Hide

      no_passthrough test:

      import {ShardingTest} from "jstests/libs/shardingtest.js";
const st = new ShardingTest({rs: {setParameter: {featureFlagCreateViewlessTimeseriesCollections: 1}}});
const db = st.s.getDB("test");
db.createCollection("myts", {timeseries: {timeField: 't'}});
print(tojson(db.myts.find().explain()));
st.stop();
      Show
      no_passthrough test: import {ShardingTest} from "jstests/libs/shardingtest.js"; const st = new ShardingTest({rs: {setParameter: {featureFlagCreateViewlessTimeseriesCollections: 1}}}); const db = st.s.getDB("test"); db.createCollection("myts", {timeseries: {timeField: 't'}}); print(tojson(db.myts.find().explain())); st.stop();
    • CAR Team 2025-06-23
    • None
    • 3
    • TBD
    • 🟥 DDL
    • None
    • None
    • None
    • None
    • None
    • None
    • 0

      Running db.myts.find().explain() over a viewless timeseries collection on a sharded cluster (whether the collection is sharded or not) will fail with an OperationFailed error such as the following:

      MongoDB Enterprise mongos> db.myts.find().explain()
uncaught exception: Error: explain failed: {
	"ok" : 0,
	"errmsg" : "Explain command on shard shard01 failed, caused by: { explainVersion: \"1\", stages: [ { $cursor: { queryPlanner: { namespace: \"test.myts\", parsedQuery: {}, indexFilterSet: false, queryHash: \"4E45B701\", planCacheShapeHash: \"4E45B701\", planCacheKey: \"36FF8BFB\", optimizationTimeMillis: 0, maxIndexedOrSolutionsReached: false, maxIndexedAndSolutionsReached: false, maxScansToExplodeReached: false, prunedSimilarIndexes: false, winningPlan: { isCached: false, stage: \"COLLSCAN\", direction: \"forward\" }, rejectedPlans: [] } } }, { $_internalUnpackBucket: { exclude: [], timeField: \"t\", bucketMaxSpanSeconds: 3600, assumeNoMixedSchemaData: true, sbeCompatible: false } } ], serverInfo: { host: \"ip-10-0-67-40\", port: 27018, version: \"8.2.0-alpha\", gitVersion: \"nogitversion\" }, serverParameters: { internalQueryFacetBufferSizeBytes: 104857600, internalQueryFacetMaxOutputDocSizeBytes: 104857600, internalLookupStageIntermediateDocumentMaxSizeBytes: 104857600, internalDocumentSourceGroupMaxMemoryBytes: 104857600, internalQueryMaxBlockingSortMemoryUsageBytes: 104857600, internalQueryProhibitBlockingMergeOnMongoS: 0, internalQueryMaxAddToSetBytes: 104857600, internalDocumentSourceSetWindowFieldsMaxMemoryBytes: 104857600, internalQueryFrameworkControl: \"trySbeRestricted\", internalQueryPlannerIgnoreIndexWithCollationForRegex: 1 }, command: { find: \"myts\", $db: \"test\" }, ok: 1.0, $clusterTime: { clusterTime: Timestamp(1748360126, 1) }, $configTime: Timestamp(1748360126, 1), $topologyTime: Timestamp(1748359687, 11), operationTime: Timestamp(1748360121, 21) }",
	"code" : 96,
	"codeName" : "OperationFailed",
	"$clusterTime" : {
		"clusterTime" : Timestamp(1748360126, 1),
		"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	},
	"operationTime" : Timestamp(1748360121, 21)
}

      The same scenario will work correctly for a "viewful" timeseries collection.
      This case should be tested by the timeseries_index_partial.js test.

            Assignee:
            Tommaso Tocci
            Reporter:
            Joan Bruguera Micó
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: