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

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 5.3.0
    • Affects Version/s: Backlog
    • Component/s: Sharding
    • Labels:
      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

      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.

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

              Created:
              Updated:
              Resolved: