-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Networking, Sharding
-
Labels:
-
Service Arch
-
ALL
-
v4.4, v4.2
-
Service Arch 2019-09-09, Service Arch 2019-09-23, Service Arch 2019-10-07, Service Arch 2019-10-21, Service Arch 2019-11-18, Service Arch 2019-12-02, Service Arch 2020-01-13, Service Arch 2020-01-27, Service Arch 2020-02-10, Service Arch 2020-02-24, Service Arch 2020-03-09, Service Arch 2020-03-23, Service Arch 2020-04-06, Service arch 2020-04-20
Before SERVER-35688, the ShardingTaskExecutor was able to observe IncompatibleWithUpgradedServer, thus preventing indefinite waits when a mongos connected to a newer mongod with a higher fcv. That ticket changed the RSM so that rather than using dbclient to do scans, we instead used a task executor, which in turn changed things so that rather than failing, we repeatedly retry the connect.
We should probably do one of:
- move the check that's currently in the ShardingTaskExecutor into some other lib that we can link into the regular task executor, so that all task executors in sharding exhibit the correct behavior
- change the RSM to have a network connect hook which crashes on that status (in sharding)
I'm on the fence which is less invasive
- is related to
-
SERVER-35688 Futurize the RSM implementation
-
- Closed
-
- related to
-
SERVER-42982 Unblacklist multiVersion/upgrade_downgrade_cluster.js
-
- Closed
-
-
-
- Closed
-