[SERVER-59053] VectorClock is not gossiped in sessions started by a direct-to-shard command Created: 03/Aug/21  Updated: 29/Oct/23  Resolved: 17/Dec/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: Backlog
Fix Version/s: 5.3.0

Type: Bug Priority: Major - P3
Reporter: Tommaso Tocci Assignee: Tommaso Tocci
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: 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
Participants:

 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.



 Comments   
Comment by Githook User [ 16/Dec/21 ]

Author:

{'name': 'Tommaso Tocci', 'email': 'tommaso.tocci@mongodb.com', 'username': 'toto-dev'}

Message: SERVER-59053 VectorClock is not gossiped in sessions started by a direct-to-shard command
Branch: master
https://github.com/mongodb/mongo/commit/affb00871f6421c72ba42270f0cfc67dc501dcc9

Comment by Kaloian Manassiev [ 13/Sep/21 ]

The vector clock also includes the config server optime and would be impossible to gossip that for direct-to-shard commands. Therefore I think we can't really provide any guarantees for direct-to-shard connections right now. It might be possible to do that once migrations start committing at the same time on both donor and recipient.

Generated at Thu Feb 08 05:46:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.