[SERVER-40990] If a createIndexes request specifies two identical indexes, a IndexAlreadyExists error is thrown and no index is ever created Created: 03/May/19  Updated: 09/Aug/19  Resolved: 09/Aug/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Benety Goh
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-40926 createIndexes should return IndexBuil... Closed
is related to SERVER-40927 createIndexes should wait for indexes... Closed
is related to SERVER-42272 IndexBuildsCoordinator crashes on ind... Closed
Operating System: ALL
Sprint: Storage NYC 2019-05-06, Execution Team 2019-08-12
Participants:

 Description   

MultiIndexBlock::init has a for-loop for initializing indexes in-memory and on disk. In the for-loop we call IndexCatalog::prepareSpecForCreate to check for errors: bad spec, already exists.

The first loop is fine, and sets up the index. The second loop will get an IndexAlreadyExists error from IndexCatalog::prepareSpecForCreate. This error will not get swallowed – we do swallow IndexAlreadyExists errors encountered earlier in the command. The user will get an IndexAlreadyExists error and no index will have been created.



 Comments   
Comment by Benety Goh [ 09/Aug/19 ]

Closing as "Won't Fix". The error codes returned from the createIndexes for the scenarios described in the previous comment should be informative enough for the user to identify and correct the invalid set of index specs.

Comment by Benety Goh [ 05/Aug/19 ]

Current behavior for identical indexes within the same createIndexes command:

  • same index name, different key pattern - IndexKeySpecsConflict
  • different index names, same key pattern - IndexOptionsConflict

Unless the desired outcome is to deduplicate index specs within the same command invocation, we can consider leaving the current behavior intact.

Comment by Benety Goh [ 02/Aug/19 ]

We current return IndexOptionsConflict for the case where two indexes within the same createIndexes command have the same key pattern:

db.runCommand({createIndexes: 't', indexes: [{name: 'a_1', key: {a: 1}}, {name: 'a_2', key: {a: 1}}]})
{
	"ok" : 0,
	"errmsg" : "Index with name: a_2 already exists with a different name",
	"code" : 85,
	"codeName" : "IndexOptionsConflict"
}

Comment by Benety Goh [ 02/Aug/19 ]

SERVER-42272 added a test case to create_indexes.js for specifying two indexes with identical names in the same createIndexes command.

Comment by Eric Milkie [ 26/Jul/19 ]

The Coordinator is running createIndexes on primaries now.

Comment by Dianna Hohensee (Inactive) [ 16/May/19 ]

This was fixed in v4.2 by adding this code in this commit. An OperationFailed error with an informative msg will be returned instead of an IndexAlreadyExists error.

We may wish to consider some other behavior, like going ahead and building the indexes that do not cause an IndexAlreadyExists error. And adding testing either way.

Comment by Dianna Hohensee (Inactive) [ 03/May/19 ]

Note: We'll need to do something for the IndexBuildsCoordinator once it is running createIndexes cmd requests on primaries.

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