[SERVER-33149] createIndexes fails to report an error when index is not created with the specified name Created: 06/Feb/18 Updated: 29/Oct/23 Resolved: 20/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 3.6.2 |
| Fix Version/s: | 4.1.10 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Robert Stam | Assignee: | Gregory Wlodarek |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||
| Steps To Reproduce: | Setup:
Reproduction (note that name is different from above):
The problem: since the server returned { ok : 1 } that implies that an index with the name "x_2" must exist. But that is not true. Expected result: Some sort of error message indicating that the second index was NOT created. Perhaps similar to the error message when trying to create a second index with conflicting options:
Suggested errmsg: Index with the same keys but a different name already exists. |
||||||||||||||||||||||||||||||||
| Sprint: | Storage NYC 2019-03-11, Storage NYC 2019-03-25 | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||||||||||||||
| Description |
|
The createIndexes command fails to report an error when an index is not created with the specified name because an index already exists with the same keys but with a different name. |
| Comments |
| Comment by Nathaniel Mishkin [ 04/Oct/21 ] |
|
Not that probably anyone much cares at this point but, for posterity I figure I'll note that I'm dealing with the fallout of this change as part of upgrading from 3.6 to 4.2 and that the comment about "potentially breaking applications" is real for me. I'm coding around the change but I want to mention that one thing that makes that change a bit more difficult than in theory it needs to be: When my code tries and fails to create an index due to the fact that an index already exists that's identical in all ways to the index the code is trying to create except in name my code will need to figure that out on its own because the error code returned by the server is INDEX_ALREADY_EXISTS (85). That error code also covers other cases–like the fact that the existing index is not unique but the index that the code is trying to create is unique–which do in fact require that the code drop the existing index before attempting to create an index. In the "differs only in name" case, my code could just ignore the error (esp. in the case of an expensive-to-create index whose transient non-existence would cause operational problems and poor behavior for my product's customers). I guess you could view this as a request for enhancement: Add a new error code that indicates that the creation failure is due to only the name being different. Also, more generally, it'd be nice if creating an index with different attributes didn't require that an existing index be dropped, but that's a whole different (and, I assume, harder to address) issue. |
| Comment by Githook User [ 20/Mar/19 ] |
|
Author: {'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'}Message: |
| Comment by Charlie Swanson [ 22/May/18 ] |
|
Just an update on this ticket: 1) This change has been approved by downstream changes, 2) There is a pull request (linked). 3) The pull request looked good to me, but failed some tests when I ran it through evergreen. One such failure was this line of fts_index.js. I'm not sure why the behavior changed there, or what to do about it. It may be an expected/desirable change and we should update the test, or it may be indicative of a problem with ensureIndex. It's unlcear to me if the '_fts' means something special in the context of createIndex. I'm handing this ticket off to the storage team, since milkie and I agree it falls more in their wheelhouse. |
| Comment by Charlie Swanson [ 04/Mar/18 ] |
|
downstreamchanges the query team thinks this is a desirable change, but are worried about potentially breaking applications that rely on this behavior. In short, this ticket requests that creating an index that has identical options to an existing index but differs only in name should be an error. Today this command succeeds (returns {ok: 1}), but with a "note" field saying that all indexes exist (see reproduction steps). Does anyone know of any reason we should not make this change? |
| Comment by Charlie Swanson [ 01/Mar/18 ] |
|
Assigning to myself to review the pull request. |
| Comment by Esha Maharishi (Inactive) [ 06/Feb/18 ] |
|
Okay, thanks, that helps with triaging Tentatively assigning to the storage backlog. |
| Comment by Robert Stam [ 06/Feb/18 ] |
|
My repro is on a standalone. Not sure how it behaves on a replica set or sharded cluster. |
| Comment by Esha Maharishi (Inactive) [ 06/Feb/18 ] |
|
rstam, is this repro for a standalone/replica set, or for a sharded cluster? |