Skip to content

feat: upgrade mongodb driver to 7.6.0 - #507

Open
romualdnave wants to merge 5 commits into
balderdashy:masterfrom
romualdnave:upgrade-mongodb-driver-7
Open

feat: upgrade mongodb driver to 7.6.0#507
romualdnave wants to merge 5 commits into
balderdashy:masterfrom
romualdnave:upgrade-mongodb-driver-7

Conversation

@romualdnave

@romualdnave romualdnave commented Sep 9, 2026 •
edited
Loading

Copy link
Copy Markdown

Summary

Upgrades the mongodb driver dependency from 6.3.0 to 7.6.0. No changes were needed in lib/ — the adapter's driver usage (MongoClient, ObjectId/ObjectID, Binary, cursor/aggregation APIs) is unaffected by the v6 → v7 changes.

sails-mongo currently bundles mongodb@6.3.0, which resolves bson@6.10.4. Any application that also depends directly on a newer mongodb/bson major (e.g. mongodb@7.x for code that doesn't go through Waterline — building native ObjectIds, running aggregations, using driver features Waterline doesn't expose) ends up with two different major versions of bson in its dependency tree at once.

Since bson v6, every BSON type (ObjectId, etc.) is tagged with the version of bson that created it, and the driver validates that tag at runtime. When a value created by one major is passed into a query that runs through the other, it's rejected:

BSONVersionError: Unsupported BSON version, bson types must be from bson 6.x.x

This surfaced for us in a NestJS + Waterline app where an ObjectId built via the app-level mongodb@7.6.0 package was assigned to a model field later saved through a Waterline model backed by sails-mongo. Related/complementary: #502 describes a similar class of bug (instanceof ObjectId failing) caused by having more than one mongodb/bson instance in the tree.

Testing

Ran the full existing suite locally against the bumped dependency (npm run docker-test, MongoDB 7 via the repo's own docker-compose.yml).

⚠️ Compatibility concerns - CI failing

mongodb@7.x raises two floors that this repo's current CI matrix doesn't meet yet:

  • Node.js ≥ 20.19.0 is now required by the driver. .travis.yml currently only builds Node 16 (18/20 are commented out).
  • MongoDB server ≥ 4.4 (wire version 9) is now required. Verified locally: connecting mongodb@7.6.0 to a MongoDB 4.2 server fails immediately with: 
    MongoServerSelectionError: Server at <host> reports maximum wire version 8, but this version of the
Node.js Driver requires at least 9 (MongoDB 4.4)

The CI fails here because the current Travis matrix (MONGODB=3.6.18/4.0.18/4.2.7) is below this floor and would need to move to 4.4+ (ideally something more current, e.g. 6.0/7.0/8.0).

There probably is a bit more than simply updating the matrix in both .travis.yml/appveyor.yml files. Which is the reason I didn't touch these two in this PR.

Happy to follow up with that including a fresher target for Node/Mongo matrix — let me know what you'd prefer.

Related

@sailsbot

sailsbot commented Sep 9, 2026

Copy link
Copy Markdown

Thanks for submitting this pull request, @romualdnave! We'll look at it ASAP.

In the mean time, here are some ways you can help speed things along:

  • discuss this pull request with other contributors and get their feedback. (Reactions and comments can help us make better decisions, anticipate compatibility problems, and prevent bugs.)
  • ask another JavaScript developer to review the files changed in this pull request. (Peer reviews definitely don't guarantee perfection, but they help catch mistakes and enourage collaborative thinking. Code reviews are so useful that some open source projects require a minimum number of reviews before even considering a merge!)
  • if appropriate, ask your business to sponsor your pull request. (Open source is our passion, and our core maintainers volunteer many of their nights and weekends working on Sails. But you only get so many nights and weekends in life, and stuff gets done a lot faster when you can work on it during normal daylight hours.)
  • make sure you've answered the "why?" (Before we can review and merge a pull request, we feel it is important to fully understand the use case: the human reason these changes are important for you, your team, or your organization.)

Please remember: never post in a public forum if you believe you've found a genuine security vulnerability. Instead, disclose it responsibly.

For help with questions about Sails, click here.

@socket-security

socket-security Bot commented Sep 9, 2026 •
edited
Loading

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security		 Vulnerability Quality Maintenance License
Updatednpm/​mongodb@​6.3.0 ⏵ 7.6.095 +110010098 +1100

View full report

@DominusKelvin DominusKelvin mentioned this pull request Sep 10, 2026
Open
@romualdnave

romualdnave commented Sep 11, 2026

Copy link
Copy Markdown
Author

@DominusKelvin as the changes in this PR would involve major changes I assumed in the migration notes added in the README (see f1b25c2) that it would be a breaking change leading to sails-mongo v3.x version hence the "Upgrading from sails-mongo v2.x" title.

There are still some decisions to make regarding CI. Some more information in issue #7382

Looking forward to your reviews :-)

@romualdnave
romualdnave force-pushed the upgrade-mongodb-driver-7 branch 2 times, most recently from 1b9507b to 899f12c Compare September 11, 2026 10:57
@romualdnave
feat: remove deprecated useNewUrlParser and useUnifiedTopology options
ce58864 
- updating MongoDB driver to 7.x+ implies complete removal of
useNewUrlParser and useUnifiedTopology options which were no-ops
until now. Removing them here will prevent sails-mongo from accepting
and forwarding them leading to a MongoParseError.
- add migration notes to the Compatibility section of README
@romualdnave
chore: modernize travis ci configuration
5f2460a 
- bump node_js matrix to 20/22/24, replacing older unsupported
versions
- update MONGODB matrix to 4.4.29/6.0.29/8.0.30: mongodb driver
7.6.0 dropped support for server versions <= 4.2, so the matrix is
repositioned on the supported floor (4.4), a mid-range version (6.0)
and the latest stable (8.0)
- switch install_mongodb.sh from ubuntu1604 to ubuntu2004 tarballs:
fastdl.mongodb.org no longer publishes ubuntu1604 builds for
mongodb 6.x/8.x, and ubuntu2004 is the only distro covering the
whole new matrix
- bump dist from xenial to focal: the mongodb install script now
downloads binaries built for ubuntu 20.04, so the travis runtime
must match to avoid a glibc/runtime mismatch
- remove the npm@8.11.0 pin: it likely existed to keep npm
identical across the previous 16/18 node matrix regardless of
whichever patch version each node build bundled; on the current,
actively-maintained node versions each already ships a recent,
consistent npm, so the pin is probably no longer required
- remove the send-metrics config key which no longer exists in
modern npm versions (see https://github.com/npm/cli/pull/2382/changes)
@romualdnave
chore: pin appveyor to visual studio 2026 image and node 22/24
45e624c 
- pin : unlike travis, appveyor doesn't
let us install an arbitrary mongodb/node version via script — the
image bundles fixed versions. every image up to vs2022 only ships
mongodb 4.0.1, below the >=4.4 floor required by mongodb driver
7.6.0; vs2026 is the only image currently shipping a compatible
mongodb (8.2.3) out of the box
- drop node 16/18/20 from the nodejs_version matrix, keep 22/24:
no appveyor windows image currently bundles a node 20.x build
>=20.19.0 (the driver's minimum) — the only 20.x available anywhere
is 20.17.0 on vs2019/vs2022, and vs2026 ships no 20.x branch at all.
22.x is the first branch clearing the floor on any image
- node 20 is dropped from windows ci only; it stays covered on
travis/linux, where an exact 20.19+ build can be installed directly
via nvm rather than relying on whatever the os image bundles
@romualdnave
romualdnave force-pushed the upgrade-mongodb-driver-7 branch from 3704171 to 45e624c Compare September 11, 2026 14:44
@romualdnave
test: add regression tests for cross-major bson ObjectId compatibility
d10108b 
- pins down the BSON version contract introduced by the mongodb 7.x
bump: an ObjectId built with the driver's own bundled bson (v7.x) is
accepted, while one built with an external bson@6.x is rejected with
a BSONVersionError.
- tests go through `.manager.collection()` directly rather than
Waterline's `.create()`, since the `id` attribute's `string` type
would otherwise intercept the ObjectId before it reaches the driver.
- add bson-v6-fixture as a devDependency (aliased to bson@6.10.4) to
construct an external, older-major ObjectId for the rejection case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@romualdnave @sailsbot