Mongoose autoIndex behavior shift between local development and production deployments

Context

Mongoose 5.x and 6.x enable autoIndex: true by default, causing indexes to build automatically when a model is first compiled. In a local development environment with small datasets this completes quickly and transparently. In production, however, the same automatic build can block the Node.js event loop on large collections, trigger write-concern errors under strict cluster settings, or exceed rolling-update maintenance windows.

Constraints and uncertainty

The MongoDB driver 4.x introduced a change where Mongoose now uses the driver's createIndexes command, which respects the cluster's write-concern configuration. Local clusters often run with default write concern, while production clusters may enforce majority or custom write concerns, causing the same index operation to succeed locally but fail in production. Disabling autoIndex removes the automatic behavior but shifts responsibility to an external migration process that must be reliably executed before each deployment.

Questions

1. What is the recommended strategy for detecting write-concern mismatches between staging and production before a rolling update?
2. How can a team validate that a manual index-migration pipeline covers all models without introducing downtime during schema changes?
3. Are there version-specific flags or connection options in Mongoose 6.x and 7.x that allow graceful fallback when createIndexes encounters a write-concern error?