[SERVER-51206] collStats command does not return an error when the collection does not exist on sharded clusters Created: 29/Sep/20  Updated: 09/Jan/24  Resolved: 09/Jan/24

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.2.9, 4.4.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Shane Harvey Assignee: Silvia Surroca
Resolution: Duplicate Votes: 0
Labels: 12/12
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by DOCS-13941 collstats command not giving error as... Closed
Duplicate
duplicates SERVER-29678 collStats should return ok:1 and all ... Closed
Related
related to SERVER-50070 collStats does not return error code ... Backlog
related to SERVER-29678 collStats should return ok:1 and all ... Closed
Assigned Teams:
Catalog and Routing
Operating System: ALL
Sprint: CAR Team 2024-01-22
Participants:
Story Points: 1

 Description   

On MongoDB 4.2/4.4 sharded clusters, the collStats command returns an error on a non-existent database but not on a non-existent collection within an existing database:

>>> client.admin.command('buildInfo')['version']
'4.2.9'
>>> client.core.test.insert_one({})
<pymongo.results.InsertOneResult object at 0x7f886b59f680>
>>> client.core.list_collection_names()
['test']
>>> client.idontexist.command("collstats", 'idontexist', check=False)
{'ok': 0.0, 'errmsg': 'database idontexist not found', 'code': 26, 'codeName': 'NamespaceNotFound', 'operationTime': Timestamp(1601349800, 22), '$clusterTime': {'clusterTime': Timestamp(1601349800, 22), 'signature': {'hash': b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'keyId': 0}}}
>>> client.core.command("collstats", 'idontexist')
{'sharded': False, 'primary': 'demo-set-0', 'indexDetails': {}, 'ns': 'core.idontexist', 'count': 0, 'size': 0, 'storageSize': 0, 'totalIndexSize': 0, 'indexSizes': {}, 'avgObjSize': 0.0, 'maxSize': 0, 'nindexes': 0, 'nchunks': 1, 'shards': {'demo-set-0': {'ns': 'core.idontexist', 'size': 0, 'count': 0, 'storageSize': 0, 'nindexes': 0, 'totalIndexSize': 0, 'indexDetails': {}, 'indexSizes': {}, 'scaleFactor': 1, 'ok': 1.0, '$gleStats': {'lastOpTime': {'ts': Timestamp(1601349779, 1), 't': 1}, 'electionId': ObjectId('7fffffff0000000000000001')}, 'lastCommittedOpTime': Timestamp(1601349809, 15), '$configServerState': {'opTime': {'ts': Timestamp(1601349809, 17), 't': 1}}, '$clusterTime': {'clusterTime': Timestamp(1601349809, 22), 'signature': {'hash': b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'keyId': 0}}, 'operationTime': Timestamp(1601349809, 15)}}, 'ok': 1.0, 'operationTime': Timestamp(1601349809, 15), '$clusterTime': {'clusterTime': Timestamp(1601349809, 22), 'signature': {'hash': b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'keyId': 0}}}

This behavior is inconsistent. On 4.0 and earlier both scenarios result in an error:

>>> client.admin.command('buildInfo')['version']
'4.0.20'
>>> client.idontexist.command("collstats", 'idontexist', check=False)
{'ok': 0.0, 'errmsg': 'database idontexist not found', 'code': 26, 'codeName': 'NamespaceNotFound', 'operationTime': Timestamp(1601350251, 2), '$clusterTime': {'clusterTime': Timestamp(1601350251, 2), 'signature': {'hash': b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'keyId': 0}}}
>>> client.core.command("collstats", 'idontexist', check=False)
{'ok': 0.0, 'errmsg': 'Collection [core.idontexist] not found.', 'code': 8, 'codeName': 'UnknownError', 'operationTime': Timestamp(1601350188, 1), '$clusterTime': {'clusterTime': Timestamp(1601350189, 1), 'signature': {'hash': b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'keyId': 0}}}

Note that there seems to be another bug here. Notice that in 4.0.20 the second error code is UnknownError when it surely should be NamespaceNotFound. This is related to SERVER-50070 but not quite the same.



 Comments   
Comment by Shane Harvey [ 29/Sep/20 ]

Yes the original ticket description only applies to sharded clusters.

In MongoDB 4.0 both replica sets and sharded clusters return an error (although very strangely it's also missing an error code):

>>> client.admin.command('buildInfo')['version']
'4.0.20'
>>> client.admin.command('isMaster')['setName']
'ce28483f-db76-419d-8edc-8ac409adce80'
>>> client.core.list_collection_names()
[]
>>> client.core.test.insert_one({})
<pymongo.results.InsertOneResult object at 0x7fa083127e80>
>>> client.idontexist.command("collstats", 'idontexist', check=False)
{'ns': 'idontexist.idontexist', 'ok': 0.0, 'errmsg': 'Database [idontexist] not found.', 'operationTime': Timestamp(1601401804, 1), '$clusterTime': {'clusterTime': Timestamp(1601401804, 1), 'signature': {'hash': b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'keyId': 0}}}
>>> client.core.command("collstats", 'idontexist', check=False)
{'ns': 'core.idontexist', 'ok': 0.0, 'errmsg': 'Collection [core.idontexist] not found.', 'operationTime': Timestamp(1601401811, 1), '$clusterTime': {'clusterTime': Timestamp(1601401811, 1), 'signature': {'hash': b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'keyId': 0}}}

Looking more into it I see this was changed in SERVER-29678. However I think SERVER-29678 only addressed the issue on mongod, not mongos. Can we make the behavior consistent between replica sets and sharded clusters? Can we also fix the missing/UnknownError error codes?

Comment by Daniel Gottlieb (Inactive) [ 29/Sep/20 ]

shane.harvey when I run collStats on just a replica set, I receive an "ok" response on both:

  • The database exists, but the collection doesn't exist.
  • The database does not exist.

I'm led to believe the error you're seeing when the database doesn't exist is specific to a sharded cluster? Am I correct in assuming you'd like to see standalones/replica sets/sharded clusters to all exhibit the same behavior?

I'm going to speculatively assume the answers to those questions are yes and assign this to execution's backlog for triaging (I'm not exactly sure if a specific team owns collStats).

Generated at Thu Feb 08 05:24:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.