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:


💭 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


🔗 Related


Auto-generated by MCP Smart Consolidation