Resharding is not supported with storage engines that don't support readConcern majority. This manifests in this ticket with dropCollection behavior. In storage engines that don't support readConcern majority, the two-phase dropCollection is run in separate storage transactions. This allows readers to see resharding collections in a quasi-renamed-but-not-yet-dropped state.

These are potential solutions:

• Fix behavior in resharding server code to tighten constraints around dropCollection. Should have no behavior change on storage engines that support the post-4.0 drop behavior (aka WiredTiger).
• Add constraints around dropCollection just in resharding unit tests in order to prevent this race from happening.
• Remove resharding unit tests that rely on dropCollection behavior and rely solely on integration tests to test this.