-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
None
-
Dotnet Drivers
-
None
-
None
-
None
-
None
-
None
-
None
Summary
A bare projection of an owned (embedded) collection's element count:
db.Blogs.Select(b => b.Posts.Count)
throws System.ArgumentException in every MongoQueryMode — Native, DriverLinq, and NativeOnly alike. Because DriverLinq never reaches the provider's native translator, this is not a native-translation decline: it is a hard failure in the projection-shaping path shared by all modes.
Note the distinction from a graceful decline, which is what "deferred" normally means in this provider's documentation: an unsupported shape usually falls back to driver-LINQ and returns correct results, throwing only under NativeOnly. This shape returns nothing in any mode.
Pre-existing — NOT introduced by the owned-collection .Count-in-a-predicate slice
Reproduced on main at 1d1e4e6 via a disposable worktree, so it predates the entire EF-322 native-query work stream. The .Count-in-a-predicate slice neither causes nor fixes it: that slice's recognition lives in MongoExpressionTranslator.TranslateOperand (predicate/operand positions), and it leaves this projection shape exactly as it was.
Scope — what does work, for contrast
An ARITHMETIC projection leaf containing an owned count goes native and returns correct values, including 0 for a missing or explicitly-null array:
db.Blogs.Select(b => new { X = b.Posts.Count * 2 })
This became native as an incidental consequence of the count being recognized as an ordinary operand, and is covered by NativeOwnedCollectionCountTests.Arithmetic_projection_leaf_containing_a_count_goes_native.
A projected REFERENCE-collection count is also supported, via $size over a $lookup output alias (NativeProjectionBinder building a MongoSizeExpression):
db.Orders.Select(c => new { c.Orders.Count })
So the gap is specific to the BARE form over an EMBEDDED array.
Suspected root cause
Attributed during investigation to a gap in the projection-binding visitor path (MongoProjectionBindingExpressionVisitor and the shared field-access resolution it feeds), which has no handling for a bare collection-Count leaf over an embedded array — as opposed to the $lookup-alias form, which NativeProjectionBinder handles explicitly. This attribution was NOT traced to a specific line and should be confirmed before fixing.
Repro / documenting test
NativeOwnedCollectionCountTests.Bare_embedded_collection_Count_projection_is_a_known_preexisting_limitation pins the current behavior across all three query modes.
The test deliberately asserts the exact exception type while documenting that the type is NOT part of the provider's contract for an unsupported shape (per the versioning rubric in AGENTS.md). Its purpose is to notice change — in either direction — and prompt re-measurement and re-documentation, not to freeze ArgumentException as expected behavior.
Suggested fix
Support the bare embedded-collection count projection natively, emitting the null-safe $size form already available on MongoSizeExpression (constructed with NullSafe: true), which renders as:
{ $size: { $ifNull: [ "$Posts", [] ] } }
and therefore correctly yields 0 for a missing or explicitly-null array. Failing that, make the shape decline gracefully so it falls back and returns correct results rather than throwing in every mode.
When fixed, update the documenting test to assert the correct values, and update the "embedded-collection projections" wording in src/MongoDB.EntityFrameworkCore/Query/AGENTS.md, which currently records this hard-fail.