[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:
Depends
is depended on by CSHARP-2152 Create index returns wrong result Closed
Documented
is documented by DOCS-12562 Docs for SERVER-33149: createIndexes ... Closed
Duplicate
is duplicated by SERVER-13290 createIndex on existing index but dif... Closed
Related
related to SERVER-43575 Duplicate index because of deprecatio... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

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.

Sprint: Storage NYC 2019-03-11, Storage NYC 2019-03-25
Participants:
Case:
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: 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

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?

Generated at Thu Feb 08 04:32:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.