dropIndexes abort semantics
Parent: MongoDB Wildcard and Hidden Indexes, Index Builds and Index Overhead · Published reference · snapshot 2026-10-21 · skill ranked-1cb7f7b2
↓ Facts as markdownall context files
Source-anchored research for dropIndexes abort semantics. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Comparisons and alternatives
- The current manual allows `dropIndexes` to remove a ready index while a different index on the same collection is building. Earlier versions returned `BackgroundOperationInProgressForNamespace` for that separate-index case. This differs from aborting a build, which targets the full builder set. (high confidence) (verified as of 2026-10-20) [source]
- MongoDB's `SERVER-37726` implementation record says aborting an in-progress build emits an `abortIndexBuild` oplog entry instead of a separate `dropIndexes` oplog entry. It gives rollback/refetch consistency as the reason for that choice. (low confidence) [source]
Facts and statements
- MongoDB 4.4 and later allow dropIndexes or its dropIndex helper to target an in-progress index; MongoDB attempts to stop that build, with the same effect as dropping the built index. (high confidence) (verified as of 2026-10-20) [source]
- For a replica set, issue the abort request on the primary. The primary stops the build and writes an `abortIndexBuild` oplog entry; secondaries that apply it stop the in-progress build and discard their local build job. MongoDB warns against using `killOp` to terminate in-progress builds in replica sets or sharded clusters. (high confidence) (verified as of 2026-10-14) [source]
- An abort targets the whole index builder. If one `createIndexes` call started several indexes together, the caller must specify every index name from that builder; the server matches the request against the builder's complete index-name set. (high confidence) (verified as of 2026-10-20) [source]
- MongoDB's current manual says not to use killOp to terminate an in-progress index build in a replica set or sharded cluster; issue dropIndexes on the primary instead. (high confidence) (verified as of 2026-10-19) [source]
- If `dropIndexes` names an index that is still being built, the command attempts to stop that build; MongoDB documents stopping it as having the same effect as dropping the completed index. (high confidence) (verified as of 2026-10-14) [source]
- MongoDB's `SERVER-46397` ticket documents a historical race: two concurrent `dropIndexes` commands on a primary could make a secondary block while applying one drop against another active build, preventing a later `abortIndexBuild` from applying. The ticket lists fixes in 4.4.0-rc0 and 4.7.0. (low confidence) [source]
Children
- No children recorded.