Summary

mongodb-runner starts servers using the Node driver, and NODE-7547 raised that driver's minWireVersion to 9 in mongodb 7.6.0, released 2026-08-24. mongodb-runner 6.8.2 depends on mongodb: ^7.2.0, so every 4.2 server it starts now fails the handshake:

MongoCompatibilityError: Server at localhost:27017 reports maximum wire version 8, but this version of the Node.js Driver requires at least 9 (MongoDB 4.4)

Two separate problems produced this, and they want separate fixes.

The driver is genuinely incompatible with 4.2, by design and on a published schedule. That needs a pinned driver for the versions mongodb-runner can no longer reach.

The breakage was a surprise because nothing in this repository records which driver we run. _install_mongodb_runner writes a package.json with a floating range and runs npm install at test time, with no lockfile, so a new npm release changes what every host runs with no commit and no signal. Nothing here changed: test-mongodb-runner-full passed on mainline on 2026-08-22 and the same revision failed two days later. The Python half of the same subsystem already avoids this, resolving mongo-orchestration and its pymongo through a committed uv.lock.

The immediate fix routes 4.2 to mongo-orchestration through the version gate in drivers_orchestration.py, which keeps a tool we want to retire on the critical path.

Motivation

Who is the affected end user?

Driver teams that still test against MongoDB 4.2, and drivers-evergreen-tools maintainers who want to retire mongo-orchestration.

How does this affect the end user?

DRIVERS-3451 is still Implementing: CDRIVER-6301, CXX-3475, JAVA-6175, PHPLIB-1833, PYTHON-5808 and RUST-2411 have not landed, so those drivers still run 4.2 and drivers-evergreen-tools still has to start it. Every 4.2 server currently comes up through mongo-orchestration rather than the path we intend to standardise on.

How likely is it that this problem or use case will occur?

Certain, and recurring. DRIVERS-2447 marks a server EOL for drivers three years after the server's own EOL, so 4.4 follows on the same schedule. Without a lockfile each one arrives unannounced, on whatever branch happens to build that day.

If the problem does occur, what are the consequences and how severe are they?

An unrelated PR goes red for a reason that is not in its diff, and the failure surfaces as a handshake error minutes into a run rather than as a dependency change.

Is this issue urgent?

No. The version gate already unblocks CI.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

Yes. This only affects how drivers-evergreen-tools starts servers for tests.

Acceptance Criteria

• The mongodb-runner install resolves from a committed lockfile, installed with npm ci so that a lockfile disagreeing with package.json fails rather than silently re-resolving.
• A new upstream release of mongodb or mongodb-runner cannot change what a test run installs. The resolved versions change only when someone updates the lockfile.
• A 4.2 server starts through mongodb-runner, using a pinned driver that still supports wire version 8.
• The pins are per server version. No global pin, so current servers keep running the current driver.
• Each entry pins mongodb-runner as well as mongodb, and the pair is validated. mongodb-runner raised its own floor from ^7.2.0 to ^7.5.0 in 6.8.4, so a driver pin below the runner's declared range needs the runner stepped back too, and an invalid pair should fail at install rather than mid-test.
• The install cache is keyed by both pinned versions. _install_mongodb_runner currently caches at TMPDIR/mongodb-runner-{_MR_VERSION}, one directory for every server version, so differing pins would collide there.
• The 4.2 entry in the version gate in drivers_orchestration.py is removed once the pins replace it.

Implementation notes

The pin itself is verified to work. Installing mongodb-runner 6.8.2 with {{"overrides":

}} resolves the driver to 7.5.0, the last release before NODE-7547.

The pinned versions have to be threaded through three call sites in .evergreen/orchestration/mongodb_runner.py, all of which install or probe the install:

• _install_mongodb_runner, which writes the package.json and owns the cache directory
• _mongodb_runner_supported, which probes by installing and so must probe the same pinned tree
• start_mongodb_runner, which installs again before starting

A lockfile prevents surprise, not incompatibility. Bumping it will still fail for 4.2 against a 7.6 or newer driver, which is what the per-version pins are for. The point is that the failure lands in the pull request that bumps it.

Out of scope

Whether drivers-evergreen-tools should keep testing 4.2 at all. DRIVERS-3582 tracks removing 4.2 from the specifications and tests, and once no driver runs 4.2 the pins for it can be deleted rather than maintained.

Note that mongo-orchestration is not a durable fallback either. PYTHON-5808 is the pymongo split of the same EOL, so once it lands and uv.lock is bumped past it, that path loses 4.2 as well.