[SERVER-50400] Migrating session info ignores ConfigurationInProgress instead of ConflictingOperationInProgress Created: 20/Aug/20  Updated: 29/Oct/23  Resolved: 25/Sep/20

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

Type: Bug Priority: Minor - P4
Reporter: Max Hirschhorn Assignee: Sergi Mateo Bellido
Resolution: Fixed Votes: 0
Labels: neweng, sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-38810 Use the Client mutex or the SessionCa... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

The changes from facdcf1 as part of SERVER-38810 introduced a transcription error. Prior to those changes, a ConflictingOperationInProgress exception would lead to the session info for retryable writes being skipped due to the recipient of the chunk migration having a higher txnNumber than the donor. A ConfigurationInProgress error is only used the replSetReconfig command.

There doesn't appear to be a way for TransactionParticipant::beginOrContinue(autocommit == boost::none) to throw a ConflictingOperationInProgress exception that I don't believe this issue is causing any chunk migrations to fail. Chunk migrations on the 4.2 branch appear to be similarly non-impacted.



 Comments   
Comment by Githook User [ 23/Sep/20 ]

Author:

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

Message: SERVER-50400 Migrating session info ignores ConfigurationInProgress instead of ConflictingOperationInProgress
Branch: master
https://github.com/mongodb/mongo/commit/1ec97a954317d55c122f33f49a3a6511b1d40ac2

Comment by Kaloian Manassiev [ 23/Sep/20 ]

sergi.mateo-bellido, in the master branch it is catching ErrorCodes::ConfigurationInProgress (which can never be thrown). The original exception was ErrorCodes::ConflictingOperationInProgress which got changed accidentally by that change. However, neither of these two errors can be thrown now, so we should just throw out this catch entry.

Comment by Kaloian Manassiev [ 16/Sep/20 ]

Assigning to Sergi.

Based on Max's observation that it us currently not possible for the TransactionParticipant::beginOrContinue call to throw this exception, I suggest that instead of fixing the catch condition, we throw out this catch clause.

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