During resetPlacementHistory InitializePlacementHistoryCoordinator drops config.placementHistory in its kDefineInitializationTime phase, but only re-creates the collection and its two secondary indexes (nss_1_timestamp_-1 unique, timestamp_-1_nss_1) two phases later, in kComputeInitialization. In between, DDLs are unblocked: the kUnblockDDLs cluster-parameter broadcast takes effect per-shard as soon as each shard receives it, even while the phase handler itself is still running.

A DDL that commits in this window writes its placement entry into the dropped collection, which implicitly re-creates config.placementHistory with only the id index. kComputeInitialization then finds a non-empty collection and must go through a two-phase index build.

If the config server primary fails over in this state, and the new primary has not run config-database initialization since process start, its step-up tries to build the missing indexes on a non-empty collection and hits the tripwire tassert 12352501 ("Illegal attempt to create an index on a non-empty collection during step-up"), followed by fassert 40184 the node crashes.

The flow from the BF logs:

* 04:10:15.552 — coordinator drops config.placementHistory on the config primary.
* 04:10:16.626 — a dropCollection_V2 commit (placement entry for the dropped collection) implicitly re-creates the collection with only _id_; replicated to all config nodes.
* 04:10:23.433 — kComputeInitialization registers a two-phase index build (collection non-empty); build exists only on the old primary.
* 04:10:23.445 — a freshly restarted node steps up; 04:10:23.452 tripwire 12352501; 04:10:23.562 fassert 40184 → crash

The race becames fatal with the step-up tripwire introduced for SERVER-132525.