[SERVER-34322] Best effort ssv to recipient shard will never succeed for the first time Created: 04/Apr/18  Updated: 29/Oct/23  Resolved: 11/Jan/22

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

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-34899 "best-effort" setShardVersion sent fr... Closed
Assigned Teams:
Sharding EMEA
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

if the recipient shard has no version initialized for the namespace.

This is because the ssv request sent has authoritative: false and will trigger this error on the recipient shard.

Another bug is that it is being sent with the collection version instead of the shard version.



 Comments   
Comment by Sergi Mateo Bellido [ 11/Jan/22 ]

Closing it after internal discussion. The issue is already fixed on versions >= 5.3.

Comment by Sergi Mateo Bellido [ 11/Jan/22 ]

As Kal mentioned above, we don't have this problem in the new migration protocol: we  send a command to the recipient shard to refresh the filtering metadata and release the critical section during the commit phase of the moveChunk.

Comment by Kaloian Manassiev [ 12/Oct/21 ]

I believe that this ticket will no longer be necessary after the work in this Epic.

Generated at Thu Feb 08 04:36:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.