[SERVER-21639] Command::execCommand should let sharding StaleConfig exceptions unroll up to receivedQuery Created: 23/Nov/15  Updated: 25/Nov/15  Resolved: 24/Nov/15

Status: Closed
Project: Core Server
Component/s: Internal Code, Sharding
Affects Version/s: None
Fix Version/s: 3.2.0-rc4

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Adam Midvidy
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-21593 findAndModify on v3.0 mongos and v3.2... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Platform D (12/11/15)
Participants:

 Description   

In mongodb version 3.2, as part of the changes to support OP_COMMAND and metadata, we are now catching all exceptions in Command::execCommand. However, this breaks backwards compatibility with older versions of mongos, which expect the ResultFlag_ShardConfigStale bit to be set on the response from the command (which is being run as a query).

Because of this, SendStaleConfigException should just be passed through by the command execution code.

Without this fix we are breaking backwards compatibility with mongos 3.0 for the findAndModify command (and possibly aggregation).



 Comments   
Comment by Githook User [ 24/Nov/15 ]

Author:

{u'username': u'amidvidy', u'name': u'Adam Midvidy', u'email': u'amidvidy@gmail.com'}

Message: SERVER-21639 set ResultFlag_ShardConfigStale on OP_QUERY command replies if needed in LegacyReplyBuilder
Branch: master
https://github.com/mongodb/mongo/commit/7f357a6865619ee32ab4f33240084f6b7c47f3ba

Comment by Adam Midvidy [ 23/Nov/15 ]

I'm going to look if there is a way we can do this in LegacyReplyBuilder without changing the existing command path code as having one error handling path makes the code much more understandable.

Comment by Kaloian Manassiev [ 23/Nov/15 ]

adam.midvidy, starting with you. I think the fix should be pretty straightforward, but wanted to see if there could be some side effects if we do not run the generic exception catching code in Command::execCommand.

Generated at Thu Feb 08 03:57:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.