[SERVER-37757] High verbosity log line in batch write path triggers invariant on bad top-level status Created: 25/Oct/18  Updated: 06/Dec/22  Resolved: 02/Nov/22

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

Type: Bug Priority: Major - P3
Reporter: Jack Mulrow Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Duplicate Votes: 0
Labels: MaxH
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-39836 Allow updates to shard key value if t... Closed
Assigned Teams:
Sharding
Operating System: ALL
Participants:

 Description   

The batch write path on mongos has this log line at level 4, that will log the batched command response from a shard if the dispatch was successful. This involves calling BatchedCommandResponse::toBSON, which uasserts the response's top-level status is OK. Any exception thrown by MongoD when running the batch write results in a command response with a top-level error, which fails this uassert on MongoS, early exiting the batch write path and then failingĀ this invariant in the BatchWriteOp destructor that all tracked writes have been cleared.

Notably, any error in a batch write in a transaction is thrown by MongoD, which would trigger this.



 Comments   
Comment by Max Hirschhorn [ 02/Nov/22 ]

This issue appears to have been addressed by the changes from 4f32712 as part of SERVER-39836 by switching to use BatchedCommandResponse::toStatus() instead of BatchedCommandResponse::toString().

Comment by Kaloian Manassiev [ 26/Oct/18 ]

Given that parseBSON already allows deserializing failed status, I don't think it is wrong to make toBSON be able to serialize it using this logic.

Marking this as 4.1 Required. At some point we should rewrite these commands to use IDL.

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