-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 4.4.0
-
Component/s: Internal Client, Internal Code
-
Sharding NYC
-
Fully Compatible
-
ALL
-
v6.3, v6.0, v5.0, v4.4
-
-
Sharding NYC 2023-03-06
-
(copied to CRM)
From documentation:
Order matters when using multiple readPreferenceTags. The readPreferenceTags are tried in order until a match is found. Once found, that specification is used to find all eligible matching members and any remaining readPreferenceTags are ignored.
This isn't true in 4.4 anymore when using multiple readPreferenceTags as a fallback.
Seems part of code location has shifted and that is the reason that readPreferenceTags behavior has changed. Or there could be other major changes with the code how matching is done regard with tags.
In 4.4 >
https://github.com/mongodb/mongo/blob/v4.4/src/mongo/client/scanning_replica_set_monitor.cpp#L1236-L1250
In 4.2 >
https://github.com/mongodb/mongo/blob/v4.2/src/mongo/client/replica_set_monitor.cpp#L1149
- is related to
-
SERVER-41910 Make RSM::getMatchingHosts return multiple hosts in the presence of tags
- Closed
- related to
-
DRIVERS-2563 Add spec test which checks that the order of read preference tag matching is obeyed
- Backlog