[SERVER-41758] Dropping config.shards is allowed and can cause mongos to crash in aggregation code Created: 14/Jun/19 Updated: 29/Oct/23 Resolved: 24/Aug/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.1, 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Bernard Gorman |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v4.2
|
||||||||
| Sprint: | Query 2019-08-12, Query 2019-08-26, Query 2019-09-09 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 0 | ||||||||
| Description |
|
Perhaps the aggregation code should handle 0 shards? Or should sharding prevent dropping config.shards? Sharding has discussed before not wanting to disallow direct writes to the config database, since sometimes people do that, and I think mongorestore might drop some of the config collections. We could also prevent the fuzzer from dropping config collections to prevent the build failures. |
| Comments |
| Comment by Githook User [ 13/Sep/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Bernard Gorman', 'username': 'gormanb', 'email': 'bernard.gorman@mongodb.com'}Message: (cherry picked from commit 1fa4766c621bd4cfd74319094469eff3a5de3b79) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 24/Aug/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Bernard Gorman', 'email': 'bernard.gorman@mongodb.com', 'username': 'gormanb'}Message: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bernard Gorman [ 11/Jul/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
esha.maharishi, kaloian.manassiev: This might be a bit trickier than it initially appears, because in the aggregation code we do handle (or at least, attempt to handle) the case where there are no shards present. We actually have at least two tests that exercise the no-shards case: current_op_no_shards.js and change_stream_no_shards.js. And dropping config.shards before running an aggregation - even on an existing sharded collection - does not crash the mongoS, but instead returns an empty cursor as expected:
So it looks like maybe BF-13560 manifests because the collection is dropped somewhere between our initial check and the point where we try to establish the cursors and hit this invariant? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kaloian Manassiev [ 05/Jul/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Regardless of whether we allow config.shards to be dropped or not (this also applies to the other collections), I don't think crash in aggregation is appropriate, so at the very least the aggregation code should be fixed to handle 0 shards. Passing this to the query team. |