[SERVER-24458] Assert that ConfigServerMetadata is always included in responses from shards Created: 07/Jun/16  Updated: 10/Feb/22  Resolved: 10/Feb/22

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

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Kaloian Manassiev
Resolution: Done Votes: 0
Labels: PM-315
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-24993 Secondaries are not tracking opTime Closed
depends on SERVER-26030 ConfigServerMetadata is not returned ... Closed
Related
is related to SERVER-23669 Make _opTime required (not boost::opt... Closed
Sprint: Sharding 16 (06/24/16), Sharding 17 (07/15/16), Sharding 18 (08/05/16), Sharding 2016-08-29, Sharding 2016-09-19, Sharding 2016-10-10, Sharding EMEA 2022-01-24, Sharding EMEA 2022-02-07, Sharding EMEA 2022-02-21
Participants:

 Comments   
Comment by Kaloian Manassiev [ 10/Feb/22 ]

The batch up/downconvert logic no longer exists since we use commands for all intra-cluster communication so I am closing this ticket as Gone Away.

Comment by Dianna Hohensee (Inactive) [ 11/Jan/17 ]

After an offline discussion, it appears that the command upconvert and downconvert isn't always handling the ConfigServerMetadata, but rather leaving it out at conversion points and thus losing it.

Putting this ticket in PM-315, because this fix should fall out of that project's completion, and then we can assert that ConfigServerMetadata is always included when it actually is.

Comment by Spencer Brody (Inactive) [ 08/Sep/16 ]

Okay, I finally understand why adding this assertion was causing things to fail.

Certain commands, like count for example, still use DBClient to run commands on the shards, which uses the legacy OP_QUERY form of running commands. On the shards, when we are using OP_QUERY, commands use a LegacyReplyBuilder to generate the command response. LegacyReplyBuilder::setMetadata only looks for ShardingMetadata and throws out all other metadata written to the metadata response (including ConfigServerMetadata, where the config server optime is given). We either need to add handling of ConfigServerMetadata to LegacyReplyBuilder::setMetadata, or switch to using OP_COMMAND for all intra-cluster communication.

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