What — mongoose.connect() resolving does not mean indexes exist: autoIndex builds run in the background and startMongoose() never awaits them. Any logic that relies on a unique index for idempotency (e.g. BillingUsage's {organizationId, weekKey} replay protection turning a duplicate upsert into a caught E11000) has a window on a brand-new database where the first writes land before the index exists — the "replay" then creates a second, distinct document instead of no-oping.
Why — On a fresh deploy (or any fresh database, e.g. an integration-test worker DB) metered usage can double-count during the index-build window. Surfaced as an intermittent replay-idempotency test failure in a downstream consumer (~1-in-5 on fresh DBs); confirmed by trace (replay write matched a different docId) and by the fix (awaiting index builds → 0 failures in 35 runs).
Scope —
lib/services/mongoose.js / lib/app.js boot: after connect + model registration, await index readiness for every model (Promise.all(modelNames.map((n) => model(n).init()))) before the app reports ready.- Adjacent bug this surfaces:
modules/billing/models/billing.usage.model.mongoose.js legacy {organizationId, month} unique index declares partialFilterExpression: { weekKey: { $exists: false } } — $exists: false is not supported in partial filters, so this index has silently never been created. Decide: fix the filter to a supported form or retire the legacy index if the month path is dead.
- Tests: boot-time assertion that indexes are ready; replay-idempotency test on a fresh DB stays deterministic.
Created via /dev:issue
What —
mongoose.connect()resolving does not mean indexes exist:autoIndexbuilds run in the background andstartMongoose()never awaits them. Any logic that relies on a unique index for idempotency (e.g.BillingUsage's{organizationId, weekKey}replay protection turning a duplicate upsert into a caught E11000) has a window on a brand-new database where the first writes land before the index exists — the "replay" then creates a second, distinct document instead of no-oping.Why — On a fresh deploy (or any fresh database, e.g. an integration-test worker DB) metered usage can double-count during the index-build window. Surfaced as an intermittent replay-idempotency test failure in a downstream consumer (~1-in-5 on fresh DBs); confirmed by trace (replay write matched a different docId) and by the fix (awaiting index builds → 0 failures in 35 runs).
Scope —
lib/services/mongoose.js/lib/app.jsboot: after connect + model registration, await index readiness for every model (Promise.all(modelNames.map((n) => model(n).init()))) before the app reports ready.modules/billing/models/billing.usage.model.mongoose.jslegacy{organizationId, month}unique index declarespartialFilterExpression: { weekKey: { $exists: false } }—$exists: falseis not supported in partial filters, so this index has silently never been created. Decide: fix the filter to a supported form or retire the legacy index if the month path is dead.Created via /dev:issue