[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: |
|
||||||||
| 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 |
| 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. |