fix(NODE-7298): ensure commonWireVersion is computed from server maxWireVersion

[crehbichler]

Description

Summary of Changes

The TopologyDescription constructor initialized commonWireVersion to 0, but the update() method only updates this field when its previous value is null. As a result, commonWireVersion remained stuck at 0 even when all servers reported valid non-zero maxWireVersion values.

This caused secondaryWritableServerSelector() to treat the cluster as pre–MongoDB 5.0 (because wireVersion < 13) and always fall back to primary read preference. User-provided read preferences (e.g. secondary, secondaryPreferred) were therefore ignored for aggregation pipelines containing write stages ($merge and $out).

The fix initializes commonWireVersion to null, allowing it to be correctly updated to the minimum non-zero maxWireVersion across server descriptions.

A new test file test/unit/sdam/topology_description.test.ts has been added to cover initialization and update behavior.

Release Highlight

Fixed Read Preference adherence for $merge and $out aggregations.

Resolved an issue where the driver failed to detect MongoDB 5.0+ capabilities due to incorrect commonWireVersion initialization. This ensures that aggregations with write stages now correctly respect secondary and secondaryPreferred read preferences, rather than forcing execution on the Primary.

Huge thanks to @crehbichler for discovering, investigating this bug and for implementing a fix!

Double check the following

• Lint is passing (npm run check:lint)
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[tadjik1]

Fantastic job @crehbichler, thanks a lot! Can you please also add integration test for the specific scenario you've found in the jira ticket, i.e. aggregate with write stages that must be issued against secondary and not primary.
For this test we can utilize command monitoring feature, similar to one in the snippet that I've shared.

[crehbichler]

Added!

I wasn’t 100% sure whether to place the integration test in aggregation or server-selection/read-preference, since the issue was more in server selection, but the result was a violation of the aggregation spec for writable stages, so I opted for aggregation.

Also, in the test I am checking the server address (I used the hello command) because the correct $readPreference was already attached to the command before the fix (just the wrong server was being selected).

Please let me know if this is fine or if I should adjust anything.

[tadjik1]

Also, in the test I am checking the server address (I used the hello command) because the correct $readPreference was already attached to the command before the fix (just the wrong server was being selected).

I think this is valid approach, another can be to issue 2 aggregate commands with and w/o readPreference and make sure their address fields are not the same (primary and secondary both being used).

[tadjik1]

@crehbichler thanks a lot for updating the PR! Some tests are failing, we will investigate failures and come back with an update in upcoming days. Sorry for the delay 🙏