[SERVER-39862] SetShardVersion can return unknown error code while refreshing from config server Created: 27/Feb/19 Updated: 29/Oct/23 Resolved: 11/Sep/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Kevin Pulo |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Minor Change | ||||
| Operating System: | ALL | ||||
| Sprint: | Sharding 2019-08-26, Sharding 2019-09-23 | ||||
| Participants: | |||||
| Linked BF Score: | 24 | ||||
| Description |
|
and this can cause the mongos/config server not to retry. Example error from build failure:
One way to fix this is to change all paths that "return false" to assert with code. |
| Comments |
| Comment by Githook User [ 11/Sep/19 ] |
|
Author: {'name': 'Kevin Pulo', 'username': 'devkev', 'email': 'kevin.pulo@mongodb.com'}Message: |
| Comment by Randolph Tan [ 15/Aug/19 ] |
|
kaloian.manassiev In this case the drop command sends the ssv here and return an error for the drop command if the ssv fails. |
| Comment by Kaloian Manassiev [ 27/Feb/19 ] |
|
I think this is happening because the setShardVersion command doesn't include the code from the returned status here. I didn't even know we are retrying on setShardVersion though, because that command is invoked from the version manager using the legacy connection code path. Or is the problem that whatever command is running upstream from this is not retrying when SSV fails - because only Map/Reduce should be doing that? |