Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
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.
JIRAUSER1262730 commented on Mon, 4 Oct 2021 14:49:05 +0000: 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. xgen-internal-githook commented on Wed, 20 Mar 2019 12:27:21 +0000: Author: {'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'} Message: SERVER-33149 createIndexes fails to report an error when index is not created with the specified name Branch: master https://github.com/mongodb/mongo/commit/7948bd50e4f43e0285fac0a11170871db81fff7c charlie.swanson commented on Tue, 22 May 2018 18:00:49 +0000: 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. charlie.swanson commented on Sun, 4 Mar 2018 16:27:15 +0000: 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? charlie.swanson commented on Thu, 1 Mar 2018 00:22:21 +0000: Assigning to myself to review the pull request. esha.maharishi@10gen.com commented on Tue, 6 Feb 2018 22:14:27 +0000: Okay, thanks, that helps with triaging Tentatively assigning to the storage backlog. rstam commented on Tue, 6 Feb 2018 22:10:14 +0000: My repro is on a standalone. Not sure how it behaves on a replica set or sharded cluster. esha.maharishi@10gen.com commented on Tue, 6 Feb 2018 22:08:27 +0000: rstam, is this repro for a standalone/replica set, or for a sharded cluster?
Setup: > use test switched to db test > db.test.drop() true > db.runCommand({ createIndexes: "test", indexes : [ { key : { x : 1 }, name : "x_1" } ] }) { "createdCollectionAutomatically" : true, "numIndexesBefore" : 1, "numIndexesAfter" : 2, "ok" : 1 } Reproduction (note that name is different from above): > db.runCommand({ createIndexes: "test", indexes : [ { key : { x : 1 }, name : "x_2" } ] }) { "createdCollectionAutomatically" : false, "numIndexesBefore" : 2, "numIndexesAfter" : 2, "note" : "all indexes already exist", "ok" : 1 } > 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: > db.runCommand({ createIndexes: "test", indexes : [ { key : { x : 1 }, name : "x_1", unique : true } ] }) { "ok" : 0, "errmsg" : "Index with name: x_1 already exists with different options", "code" : 85, "codeName" : "IndexOptionsConflict" } > Suggested errmsg: Index with the same keys but a different name already exists.