Bugfix: Why does the DEPLOY phase fail with E11000 duplicate key err...

Documentation for Sessions

🐛 Bugfix: Why does the DEPLOY phase fail with E11000 duplicate key err...

Date: 2026-02-23
Time: 21:18:21 UTC
Session: gspace1-139.4
Agent: angular
Confidence: 96%
Status: ✅ Documented

📋 Decision Context

Question:

Why does the DEPLOY phase fail with E11000 duplicate key error on moduleId when re-generating, and why doesn't the URL update with processId?

Task: S138 fix MongoDB duplicate key + URL redirect

🎯 Decision Made

Chosen:

Changed saveModule() from find-then-create to findOneAndUpdate with upsert:true keyed on {moduleId, spaceId}. Also added auto-drop of stale standalone moduleId_1 index via schema.on('index') handler. Fixed URL redirect by adding direct sessionId check in SSE subscription next handler as fallback to the constructor effect.

Options Considered:

  1. Add unique compound index migration script
  2. Change saveModule to findOneAndUpdate with upsert on moduleId+spaceId

💭 Reasoning

The E11000 error is caused by a stale standalone unique index moduleId_1 that was supposed to be removed in Session 52.2 but only the Mongoose schema was updated (to compound {moduleId, spaceId}), not the actual MongoDB index. The old index blocks any insert with a previously-used moduleId regardless of spaceId. The findOneAndUpdate with upsert approach is idempotent — re-runs simply update existing documents instead of creating duplicates. The auto-drop handler ensures the old index is removed on next server start. The URL redirect wasn't firing because the effect() in the constructor depends on the activeSessionId signal updating AND change detection running, which may not happen reliably during SSE event processing. Adding a direct check in the subscription's next handler ensures the URL updates on the very first SSE event.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation