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

VectorClock is not gossiped in sessions started by a direct-to-shard command

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major - P3 Major - P3
    • 5.3.0
    • Backlog
    • Sharding
    • None
    • Fully Compatible
    • ALL
    • Sharding EMEA 2021-08-09, Sharding EMEA 2021-09-20, Sharding EMEA 2021-10-04, Sharding EMEA 2021-10-18, Sharding EMEA 2021-11-01, Sharding EMEA 2021-11-29, Sharding EMEA 2021-12-13, Sharding EMEA 2021-12-27

    Description

      This ticket came out from a TODO in jstests/sharding/move_chunk_allowMigrations.js

      Unfortunately we can't re-enable the assertion on the ShardVersion. In fact in this specific test we are directly invoking the _configsvrSetAllowMigrations from the client, thus the command is executed in the configserver with a Client whose session is marked as `external`.
      When the config server use the ARS to tell all the shard to refresh it won't propagate the last config optime because the session in use is an external one. So the shard could possibly refresh using an afterClusterTime that is not inclusive of the latest minor version update.

      Attachments

        Activity

          People

            tommaso.tocci@mongodb.com Tommaso Tocci
            tommaso.tocci@mongodb.com Tommaso Tocci
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: