Note: This post was inspired by my attempts to find a direct download for the MongoDB Java driver, but I've left the category as "Unspecified" because it could apply to any driver download for which the official sites say to "Just use Maven/etc"

Right now the documentation for the MongoDB Java driver (https://mongodb.github.io/mongo-java-driver/4.2/driver/getting-started/installation/) indicates that "The recommended way to get started using one of the drivers in your project is with a dependency management system." However, as far as I could tell from my own research, the official MongoDB sites have no official direct download link for the driver/dependency jar files - only the Maven groupId/artifactId are provided. If for some reason a developer is restricted such that they cannot use a dependency manager for their project and must obtain the jar files as a direct download, they must find the official Apache Maven repository on their own, and download the files from there.

I understand that this seems like a problem that can be solved by saying "just suck it up and use Maven", but please understand that at its core, this actually constitutes a security issue, as it makes it difficult for developers to find a download that they know they can trust.

Consider the following situation: Due to some situation, a developer is unable to use a dependency manager for their project. They must use a direct download of the driver/dependency jar files for the MongoDB Java driver in order to do their job. The first thing they will likely do (rightfully so) is go to the official MongoDB sites to try and find a download. They will not find it, and will instead look elsewhere.

Performing a Google search for "mongodb java driver" returns first the official MongoDB sites, which the developer already knows will not help them, and then returns an unofficial Maven Repository browser (mvnrepository). I haven't looked into the validity of this site, and I'm usually one to assume the best of intentions, but the fact remains that it's run by a person who is not affiliated with Apache/Maven or MongoDB, from which the developer will likely download several unverified jar files and include them with their project. This is a big security risk, as theoretically speaking, for all we know this site could be malicious, but it remains the most convenient option for the developer, because the official MongoDB sites do not include one. The safest option for the developer is to use the official Maven repository at search.maven.org, but this site only appears at the very bottom of the first page of the Google results, and the developer may not even see this during their search.

I feel like this problem could be fully solved by creating a section on the "Downloads" page (https://www.mongodb.com/try/download) for drivers, and including the most recent normally-supported release of each driver, including its dependencies. This may not be the recommended method, and it could very well include prominent text encouraging developers to consider using a dependency manager if possible, but it would effectively remove the potential for developers to accidentally download a malicious jar file from an unverified source and include it with their project.

TL;DR: If you don't include a direct downloads for MongoDB drivers/dependencies, a malicious actor on the internet will.

I was building the URI in a spring configuration file as
spring.data.mongodb.uri=${MONGODB_URI}/test?retryWrites=true&w=majority

where MONGODB_URI came from a kubernetes secret (as it contains user & password)

somehow a new-line had slipped into the kubernetes secret, so the query was effectively asking for "fpos-dev-pl-1.kqybg.mongodb.net\n"

Besides learning how to correctly configure secrets, I learned in the process that neither Spring nor mongo was validating that spring.data.mongodb.uri was a well-formed URI and the application failed to start with error messages relating to not finding DNS and not being able to resolve the TXT record. This was very confusing.

The driver should accept a URI parameter (instead of a String) and ensures that it is valid.

Long-running transactions may trigger an aborted transaction, but the cause is not clearly communicated by the driver exception message.

Failed: Command insert failed: Transaction 1 has been aborted..
Unhandled exception. MongoDB.Driver.MongoCommandException: Command insert failed: Transaction 1 has been aborted..

To reproduce, set a very low timeout:

replicaset:PRIMARY> db.adminCommand( { setParameter: 1, transactionLifetimeLimitSeconds: 1 } )

Then run a long running transaction from the C# driver.

The cause can be confirmed by checking the MongoDB log for a [abortExpiredTransaction]:

replicaset:PRIMARY> show log global

2020-07-31T03:59:49.196+0000 I COMMAND [abortExpiredTransactions] Aborting transaction with txnNumber 1 on session xxxxxx because it has been running for longer than 'transactionLifetimeLimitSeconds'
2020-07-31T03:59:49.196+0000 I TXN [abortExpiredTransactions] transaction parameters:{ lsid: { id: UUID("xxxxxx"), uid: BinData(0, xxxxxx) }, txnNumber: 1, autocommit: false, readConcern: { level: "snapshot" } }, readTimestamp:Timestamp(0, 0), terminationCause:aborted timeActiveMicros:51529 timeInactiveMicros:7004962 numYields:0 locks:{ ReplicationStateTransition: { acquireCount: { w: 3 } }, Global: { acquireCount: { w: 2 } }, Database: { acquireCount: { w: 2 } }, Collection: { acquireCount: { w: 2 } }, Mutex: { acquireCount: { r: 2 } } } storage:{} wasPrepared:0, 7056ms

It would be extremely useful for tracking down the cause if the driver exception message could communicate more detail as contained in the server log, e.g.,

"Aborting transaction with txnNumber 1 on session xxxxxx because it has been running for longer than 'transactionLifetimeLimitSeconds'"

python and other drivers offer to-json utils. This makes taking a native rich shape complete with datetimes and byte[] and such and easily turning into bson (the best way!) or JSON. The utils offer options to modify the output representations of types but always do so in an EJSON way, namely with $date/$numberDecimal etc. Sometimes a consumer cannot (or will not) accept data in this fashion. I'd like to see a "safePureJSON" option (or similar) for bson.json_utils.dumps() that emits the safe string or number equivalent of the EJSON.
fld: {$date: "ISOdate"} becomes fld: "ISOdate"
fld: {$numberDecimal: "99.9"} becomes fld: "99.9" (string, to prevent float parse issues)
fld: {$numberLong: "1234567890123456"} becomes fld: 1234567890123456

float and int32 are not a problem.
Not as much of a issue for $binary because the extra info is probably helpful for the decoding rather than a hindrance.

This is probably not Node Specific a general problem with connecting via a seed list.

ServerSelection via seed list is a great concept. It works poorly. I have attached an hour of starting a working webserver app and 30 times starting it in a little over an hour. It failed to connect over 40 % of the time. A larger amount of successful connections were made over 35 seconds which means they would fail in a hosting environment like Heroku. Only 10% of the time did it connect in < 6 seconds. Your support team is avoiding using seed lists in their troubleshooting. A tool would allow them to get the data of the API calls in question Lastly, this would cleanup a lot of bad answers to connectivity issues and then the port driver team could fix the problem.

I'm trying to build a verbose mode in our MongoDB wrapper library. I was able to implement debug output leveraging CommandSubscriber interface. This part works.
However what I would also like to do is create support for automatic explaining of queries that are being executed. This is not possible due to inconsistency in MongoDB (php) library.

• CommandStartedEvent::getCommand() is not an instance of Explainable interface. It's just a deserialized object. There is no way to fetch the original command object to be able to do explain.
• Neither it is possible to remember such command object when creating it. As these are generated within the library itself. See functions of Collection class for example.