[JAVA-3524] MongoClient.listCollectionNames() returns truncated names Created: 05/Dec/19  Updated: 27/Oct/23  Resolved: 06/Dec/19

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: 3.10.0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Dan Dragut Assignee: Jeffrey Yemin
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We found an issue with version 3.10.0 and Azure CosmosDB where it returns shortened collection names with first 3 letters removed?

Testing with version 3.9.1 it appears to work correctly.

3.10.0 - BUG !!!

gockChangeLog,
tCreateCollection,
metricDEK,
-DEK,
gockLock,
tKey

3.9.1 - OK

mongockChangeLog,
 testCreateCollection,
 SymmetricDEK,
 PKI-DEK,
 mongockLock,
 testKey

Please let me know if there any other information you need or if you could give me a direct where I can concentrate do debug this issue and help resolve it.

Thank you,
Dan

spring.data.mongodb.uri=mongodb://...:...@xxx.documents.azure.com:10255/?ssl=true&replicaSet=globaldb

mongoDB = this.mongoClient.getDatabase(mongodb); var collectionNames = StreamSupport.stream( 
 
 
mongoDB.listCollectionNames().spliterator(), false) .collect(Collectors.toList()); 
 
log.debug("mongoClient.listCollectionNames():\n{}", String.join(", ", collectionNames));



 Comments   
Comment by Jeffrey Yemin [ 05/Dec/19 ]

Hi a.defrancesco@reply.it,

This is really a bug with CosmosDB, not with the driver. I suggest you open a bug report with CosmosDB so that they can fix the problem on their end.

Comment by Dan Dragut [ 05/Dec/19 ]

Thank you @Jeffrey Yemin

Enabling DEBUG didn't help much in finding out why the problem occured, but it just happens that I tried it again on a different environment with a much longer database name to find out that it was crashing in ListCollectionsOperation.projectFromFullNamespaceToCollectionName() when trying to remove the database name from the collection name(s). In previous context it was removing the 3 letters as the database name was 2 characters long plus the "." making it 3.

Debugging through the code with the two versions mentioned I found out that Azure CosmoDB returns only the collection names without the database name (in database.collection notation) and more importantly it appears it has different execution paths which now causes this issue.

With version 3.9.1 it didn't go through the replace logic, it just went:

MongoMappingCursor.next()
 > MongoBatchCursorAdapter.next()
 > QueryBatchCursor.next()

where with 3.10.0 (and later) it now goes through:

MongoMappingCursor.next()
 > MongoBatchCursorAdapter.next()
 > ListCollectionsOperation.ProjectingBatchCursor.next()
 > ListCollectionsOperation.ProjectingBatchCursor.projectFromFullNamespaceToCollectionName()

which either removed as many letters as the database name plus "." if a shorter database name than the collection names or it would crash if the database name would be longer than the collection names, depending on the context.

Now I don't know much about the internals of the library, but if there is no option to detect the platform and the format it returns the collection names in (database.collection or simply collection), a solution to still make it work with Azure CosmosDB would be to check if the database name is present in the collection name before trying to remove it, something like:

private List<T> projectFromFullNamespaceToCollectionName(final List<BsonDocument> unstripped) {
    if (unstripped == null) {
        return null;
    }
    List<T> stripped = new ArrayList<T>(unstripped.size());
    String prefix = databaseName + ".";
    for (BsonDocument cur : unstripped) {
        String name = cur.getString("name").getValue();
->      //
->      // FIX: Remove prefix if present...
->      //
->      if (name.startsWith(prefix)) {
          String collectionName = name.substring(prefix.length());
          cur.put("name", new BsonString(collectionName));
->      }
        stripped.add(decoder.decode(new BsonDocumentReader(cur), DecoderContext.builder().build()));
    }
    return stripped;
}

If you agree with this, please me know and I can try to create a proper patch for it.

Thank you,
Dan

Comment by Jeffrey Yemin [ 05/Dec/19 ]

Hi a.defrancesco@reply.it

We don't test against CosmosDB.  If you can reproduce this with MongoDB itself, we can take a closer look.

If you want to debug yourself, you can try enabling DEBUG logging in your application in order to log what CosmosDB is actually returning from the listCollections command.

Generated at Thu Feb 08 08:59:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.