[SERVER-54566] Fixing the ShardServerCatalogCacheLoader behavior when handling an update metadata format task Created: 13/Feb/21  Updated: 29/Oct/23  Resolved: 16/Feb/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Bug Priority: Major - P3
Reporter: Sergi Mateo Bellido Assignee: Sergi Mateo Bellido
Resolution: Fixed Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2021-02-22
Participants:
Linked BF Score: 0

 Description   

The goal of this ticket is to fix 3 minor issues introduced when working on SERVER-53104:

  • Do not assume that after an update metadata format task we will always have a common task that updates some chunks. This is only true if the Chunks we got from the Config Server are more recent than the ones we have locally.
  • I found another minor bug when we compute the enqueued metadata CollAndChangedChunks: at this point we shouldn't set the flag to false but propagate whatever value we have in task.updateMetadataFormat.
  • Finally, when we are patching-up (i.e. adding/removing the timestamp) the results that are going to be sent back to the CatalogCache, we need to first update the Collection Info and then patch-up the ChangedChunks, but we are doing it the other way around.


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

Author:

{'name': 'Sergi Mateo Bellido', 'email': 'sergi.mateo-bellido@mongodb.com', 'username': 'smateo'}

Message: SERVER-54566 Fixing the CatalogCacheLoader behavior when handling an update metadata format task

It fixes 3 things:

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