Implementation: How should Platform Elements handle the BSON version mismatc...
Documentation for Sessions
⚙️ Implementation: How should Platform Elements handle the BSON version mismatc...
Date: 2026-03-25
Time: 18:10:21 UTC
Session: gspace1-269.3
Agent: backend
Confidence: 98%
Status: ✅ Documented
📋 Decision Context
Question:
How should Platform Elements handle the BSON version mismatch causing PUT/DELETE failures?
Task: Not specified
🎯 Decision Made
Chosen:
Pin mongodb to ~6.20.0 in package.json (matching mongoose 8.20's internal dependency) + use Types.ObjectId from mongoose instead of ObjectId from mongodb on BSON-sensitive paths (update/delete). Root cause: two bson versions (6.x from mongoose, 7.x from direct mongodb@^7.0.0) caused ObjectId type mismatch at runtime.
Options Considered:
- No alternatives documented
💭 Reasoning
The package.json had mongodb: ^7.0.0 while mongoose 8.20 internally depends on mongodb ~6.20.0. This created two bson versions in node_modules (6.10.4 and 7.0.0). When data.controller.ts imported ObjectId from top-level mongodb (bson 7.x) and passed it through mongoose's internal mongodb (bson 6.x), the driver rejected the type mismatch. The fix has two layers: (1) pin the direct dependency to match mongoose, (2) use Types.ObjectId from mongoose on write paths as defense-in-depth.
📁 Files Involved
package.jsonAPIs/backend-api/src/app/data/data.controller.ts
🔗 Related
- Decision ID:
dev_1774462221003_f6tgxy7 - Session: 269
- Workspace: gspace1
Auto-generated by MCP Smart Consolidation