[SERVER-31232] remove retrying on stale shardVersion errors from cluster_aggregate.cpp Created: 22/Sep/17 Updated: 06/Dec/22 Resolved: 03/Oct/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Sharding |
| Affects Version/s: | 3.5.13 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Sharding
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
This StaleConfigException is caught at the top of mongos in generic command processing, and the command gets retried from the beginning. So, a command need not intercept stale shardVersion errors and perform any complicated retry logic itself. This will fix a bug in aggregation, where if a sharded collection is dropped and recreated as a view, the view definition response was not handled by the aggregation code on mongos. |
| Comments |
| Comment by Esha Maharishi (Inactive) [ 03/Oct/18 ] |
|
Great, closing as a dupe |
| Comment by Nicholas Zolnierz [ 03/Oct/18 ] |
|
esha.maharishi yep this was done as part of |
| Comment by Esha Maharishi (Inactive) [ 03/Oct/18 ] |
|
Maybe nicholas.zolnierz or charlie.swanson can confirm - I agree at least some of the stale version exceptions are now bubbled up to the top-level retry loop, but I'm not sure if there are any branches in agg that still catch them. |
| Comment by David Storch [ 03/Oct/18 ] |
|
esha.maharishi, if I'm not mistaken, this work has been completed under a different ticket. |