[SERVER-43957] listCollections should not return an InvalidViewDefinition error when 'filter' is {type: 'collection'} Created: 11/Oct/19  Updated: 27/Oct/23  Resolved: 11/Oct/19

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

Type: Bug Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

Reproducer:

diff --git a/jstests/core/list_collections_no_views.js b/jstests/core/list_collections_no_views.js
index ed2c1b95d0..172b3694e5 100644
--- a/jstests/core/list_collections_no_views.js
+++ b/jstests/core/list_collections_no_views.js
@@ -47,7 +47,7 @@ assert.eq(allExpected,
 // {type: {$exists: false}} is needed for versions <= 3.2
 let collOnlyCommand = {
     listCollections: 1,
-    filter: {$or: [{type: 'collection'}, {type: {$exists: false}}]}
+    filter: {type: 'collection'} //{$or: [{type: 'collection'}, {type: {$exists: false}}]}
 };
 
 let collOnly = mydb.runCommand(collOnlyCommand);
@@ -108,7 +108,7 @@ assert.eq(viewOnlyExpected,
 let views = mydb.getCollection('system.views');
 views.insertOne({invalid: NumberLong(1000)});
 
-let collOnlyInvalidView = mydb.runCommand(collOnlyCommand);
+let collOnlyInvalidView = assert.commandWorked(mydb.runCommand(collOnlyCommand));
 assert.eq(collOnlyExpected,
           collOnlyInvalidView.cursor.firstBatch
               .map(function(c) {

Test failure:

python3 buildscripts/resmoke.py --suites=replica_sets_jscore_passthrough --repeat=1 --basePort=43000 jstests/core/list_collections_no_views.js

SERVER-25942 was supposed to allow listCollections with a filter {type: 'collection'} to not fail on views errors.

The committed JS test, list_collections_no_views.js, adds additional filtering,

{$or: [{type: 'collection'}, {type: {$exists: false}}]}

, where {type: {$exists: false}} is supposed to only be needed for versions <= v3.2 compatibility, but the listCollections cmd doesn't work without error if just given {type: 'collection'} for the filter.

I did not explore how far back this behavior goes.



 Comments   
Comment by Dianna Hohensee (Inactive) [ 11/Oct/19 ]

I'm not particularly familiar with how filters work. SERVER-25942 says in a comment that the plan is to "skip loading view definitions (and therefore validating views) when listCollections is called with a 'type' filter of 'collection'", and list_collections_no_views.js has a comment suggesting that the {'$exists': false} clause is only needed for compatibility with v3.2 and earlier servers. So I concluded listCollections with just the filter {type: 'collection'} should work.

SERVER-25493 seems to indicate, however, that the compatibility logic is in the server: I thought the JS test code was just being compatible with v3.2 binaries. I'll close this ticket, then, since SERVER-25493 seems to cover it.

Thanks for the infos.

Comment by Max Hirschhorn [ 11/Oct/19 ]

What exactly is the bug here? The listCollections command compares the exact BSON of the filter to the return value from the makeTypeCollectionFilter() function in order to decide whether to skip resolving the view catalog. SERVER-25493 is still unresolved so the $exists clause is still necessary.

// TODO SERVER-25493: Remove $exists clause once MongoDB versions <= 3.2 are no longer supported.
BSONObj ListCollectionsFilter::makeTypeCollectionFilter() {
    return BSON("$or" << BSON_ARRAY(BSON("type"
                                         << "collection")
                                    << BSON("type" << BSON("$exists" << false))));
}

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