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

Release notes highlight

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.

[baileympearson]

Technically TopologyDescription is public 🫤 .

So, widening the type like this is technically a breaking change. Is it possible to fix this bug in a way that doesn't change the type of commonWireVersion?

[baileympearson]

(Any type/class/object marked with the @public tag is a part of our public API).