Mongo pipeline builder: match() equality on _id never matches — resolveValue walks bson ObjectId as a plain object

[nurul3101]

Package and version

@prisma-next/mongo-adapter / @prisma-next/mongo-query-builder @ 0.14.0 (repo main @ 284a838)

What happened?

A pipeline builder match() with an equality filter on _id never matches any document — it silently returns zero rows for both value forms:

• passing the hex string (f._id.eq('665f0c…')) — this typechecks cleanly, making it a silent zero-rows trap;
• passing a bson ObjectId instance.

The cause is in resolveValue() (packages/3-mongo-target/2-mongo-adapter/src/resolve-value.ts): after the MongoParamRef / null / Date / Array checks, any other object falls into the generic-object branch, which walks it with Object.entries() and rebuilds it as a plain object. A bson ObjectId therefore gets destructured into its internal buffer property and reaches the wire as a plain { buffer: … }-shaped document instead of an ObjectId, so the equality comparison against the stored ObjectId is never true. The hex-string form likewise never becomes an ObjectId on the encode path.

What did you expect to happen?

An _id equality filter matches the stored document: hex strings are encoded to ObjectId via the mongo/objectid@1 codec, and ObjectId instances pass through to the driver untouched (i.e. resolveValue needs a BSON-type guard alongside the existing Date guard).

Minimal reproduction

const inserted = await run(query.from('orders').insertOne({ status: 'active' }));
const id = inserted.insertedId; // hex string per the read surface

const rows = await run(
  query
    .from('orders')
    .match((f) => f._id.eq(id)) // typechecks; also fails with new ObjectId(id)
    .build(),
);
// rows === []  — expected the inserted document

Reproduced against mongodb-memory-server with a failing spec (specs/pipeline-builder.mongo.spec.ts in a local docs-validation harness); both the hex-string and ObjectId variants return [].

Environment

• Node: 24.x
• OS: macOS 15 (Darwin 24.6.0)
• Package manager: pnpm
• Database: MongoDB via mongodb-memory-server

Additional context

Related but distinct from #577, which is about the decode side (create() returning raw ObjectId instead of the hex string). This issue is the encode side: filter values are never turned into ObjectIds, so _id equality is unusable from the pipeline builder. Found while validating the examples in docs/reference/Mongo Pipeline Builder.md against the runtime.

[ankur-arch]

Still reproduces on @prisma-next/mongo@0.16.0, and the scope is wider than _id: equality on any ObjectId-typed field silently matches nothing, including relation foreign keys.

const alice = await db.orm.users.where({ email: 'alice@example.com' }).first();
// alice._id is a plain hex string at runtime (typeof === 'string')

const plan = db.query
  .from('posts')
  .match((f) => f.authorId.eq(alice._id))   // typechecks, compiles, returns []
  .group((f) => ({ _id: f.kind, postCount: acc.count() }))
  .build();

The compiled plan carries the raw string ({ kind: 'field', field: 'authorId', op: '$eq', value: '6a689c17…' }), so the $match compares a string against stored ObjectIds and returns zero rows. This makes the trap especially easy to hit in ORM-to-pipeline handoffs: ids sourced from ORM reads are strings, they satisfy the builder's types, and nothing fails.

Both workarounds verified on 0.16.0:

• db.query.rawCommand(new RawAggregateCommand('posts', [{ $match: { authorId: new ObjectId(String(id)) } }, …])) — a real ObjectId in a raw pipeline matches correctly;
• the ORM client (db.orm.posts.where({ authorId })) encodes both _id and FK fields properly.

So the fix in resolveValue should apply the mongo/objectid@1 codec for any field whose contract type is ObjectId, not just _id. Hit while validating the v6-to-Next MongoDB migration guide (prisma/web#8111); the guide now documents the rawCommand workaround.