Package and version
@prisma-next/mongo-orm (raw collection surface) @ 0.14.0 (repo main @ 284a838)
What happened?
The raw Mongo surface cannot express returnDocument or sort on findOneAndUpdate, even though the command AST supports both:
Practical consequence: with the driver defaulting to returnDocument: 'before', the standard atomic-counter idiom findOneAndUpdate(filter, { $inc: … }, { upsert: true }) returns an empty result on the first call (there is no "before" document), and there is no way to ask for the post-update document.
What did you expect to happen?
findOneAndUpdate on the raw collection accepts { upsert?, returnDocument?, sort? } and forwards them into RawFindOneAndUpdateCommand, matching what the AST already models.
Minimal reproduction
const result = await run(
raw.collection('counters').findOneAndUpdate(
{ _id: 'orders' },
{ $inc: { seq: 1 } },
{ upsert: true }, // returnDocument / sort not expressible
),
);
// first call: [] — driver default returnDocument 'before' returns the (non-existent) pre-image
Reproduced against mongodb-memory-server in a local docs-validation harness.
Environment
- Node: 24.x
- OS: macOS 15 (Darwin 24.6.0)
- Package manager: pnpm
- Database: MongoDB via mongodb-memory-server
Additional context
The typed pipeline builder's findOneAndUpdate does expose returnDocument (defaulting to 'after'), so this gap is specific to the raw surface — and the raw surface is exactly where escape-hatch patterns like upsert counters live.
Package and version
@prisma-next/mongo-orm(raw collection surface) @ 0.14.0 (repomain@ 284a838)What happened?
The raw Mongo surface cannot express
returnDocumentorsortonfindOneAndUpdate, even though the command AST supports both:RawFindOneAndUpdateCommand(packages/2-mongo-family/4-query/query-ast/src/raw-commands.ts:105-127) carriessortandreturnDocument: 'before' | 'after'fields;RawMongoCollection.findOneAndUpdate(packages/2-mongo-family/5-query-builders/orm/src/raw-collection.ts:81-89) only acceptsoptions?: { upsert?: boolean }and never forwards the other two, so they are alwaysundefinedon the wire.Practical consequence: with the driver defaulting to
returnDocument: 'before', the standard atomic-counter idiomfindOneAndUpdate(filter, { $inc: … }, { upsert: true })returns an empty result on the first call (there is no "before" document), and there is no way to ask for the post-update document.What did you expect to happen?
findOneAndUpdateon the raw collection accepts{ upsert?, returnDocument?, sort? }and forwards them intoRawFindOneAndUpdateCommand, matching what the AST already models.Minimal reproduction
Reproduced against mongodb-memory-server in a local docs-validation harness.
Environment
Additional context
The typed pipeline builder's
findOneAndUpdatedoes exposereturnDocument(defaulting to'after'), so this gap is specific to the raw surface — and the raw surface is exactly where escape-hatch patterns like upsert counters live.