Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-42919

Abort mongos upon IncompatibleWithUpgradedServer error

    XMLWordPrintableJSON

Details

    • 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

    Description

      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

      Attachments

        Issue Links

          Activity

            People

              backlog-server-servicearch Backlog - Service Architecture
              jason.carey@mongodb.com Jason Carey
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated: