[SERVER-74578] getShardVersion command should alert the user in some way if the max bson size was exceeeded Created: 03/Mar/23  Updated: 29/Oct/23  Resolved: 17/Apr/23

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 7.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Allison Easton Assignee: Allison Easton
Resolution: Fixed Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding EMEA
Backwards Compatibility: Fully Compatible
Sprint: Sharding EMEA 2023-04-03, Sharding EMEA 2023-04-17
Participants:

 Description   

The cluster getShardVersion command and the shard getShardVersion command will append all chunks + all global indexes if fullMetadata is set to true. However, if the list of chunks and indexes exceeds the max bson size, the user could get a partial list or nothing at all.

In the cluster command, if the list of chunks is going to exceed the max bson size, we will not return any chunks whereas for indexes, we will append a partial list of indexes. The shard command has the same behavior as the cluster command for indexes , but doesn't check the bson size for chunks.

In the cases where the BSON size is exceeded and we are returning partial or empty responses to the user, we should indicate to the user in some way that the returned metadata is incomplete.



 Comments   
Comment by Githook User [ 17/Apr/23 ]

Author:

{'name': 'Allison Easton', 'email': 'allison.easton@mongodb.com', 'username': 'allisoneaston'}

Message: SERVER-74578 getShardVersion command should alert the user in some way if the max bson size was exceeeded
Branch: master
https://github.com/mongodb/mongo/commit/09d703220ae751ea6005eba492a0a7158dbd8a1d

Comment by Allison Easton [ 16/Mar/23 ]

Added some links. In 3/4 cases, we are checking if the BSON we will return is too big, but then are just returning partial or no results if it is. So the user could end up thinking that the metadata is corrupted when really they just had too many chunks or indexes.

Generated at Thu Feb 08 06:27:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.