[SERVER-81800] TS Collections report incorrect namespace in $collStats output Created: 03/Oct/23  Updated: 01/Feb/24  Resolved: 01/Feb/24

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 6.0.10
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Jack Weir Assignee: Santiago Roche
Resolution: Cannot Reproduce Votes: 0
Labels: greenerbuild, time-series
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Query Integration
Operating System: ALL
Steps To Reproduce:

Deploy a MongoDB atlas cluster that supports time series (>5.0). I've reproded on 6.0.10 and 7.0.1

 

Create a timeseries collection

Run the collStats command on the collection, observe that the correct namespace is reported

Run the $collStats aggregation on the collection, observe that the reported collection name is prepended with system.buckets

Participants:

 Description   

When a the $collStats aggregation is executed against a timeSeries collection, the namespace is reported as .<dbName>.system.buckets.<actualCollectionName>

When the collStats command is run on the same collection, it correctly reports the namespace as <dbName>.<actualCollectionName>

 

I've been able to reproduce this issue in MongoDB 6.0.10 and 7.0. Attaching example outputs from both the command and the agg stage



 Comments   
Comment by Santiago Roche [ 01/Feb/24 ]

Hi colleagues,

I tried reproducing this issue on both 7.0 and 6.0 but wasn't able to. In both cases (collStats & $collStats), the namespace returned for a timeseries collection does not include "system.buckets", instead just <dbName>.<collectionName>.

Comment by Alison Rhea Thorne [ 03/Oct/23 ]

Reported behavior is that there is a difference between the Namespace for $collStats as an aggregation operator vs as an individual command. Specifically, <dbName>.system.buckets.<collectionName> is present for the aggregation operator, vs <dbName>.<collectionName> when run as a command.

Generated at Thu Feb 08 06:47:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.