Summary

EF-379 gates the two ROOT-entity-type navigation tiers in RebindInnerShaperToOuterQuery behind a root-vs-transitive classification of the join hop. ClassifyJoinHop returns Unclassifiable for a receiver that does not peel back to the key selector's own parameter, and an Unclassifiable hop deliberately falls through to the root tiers (byte-identical to pre-EF-379 behaviour).

That fall-through is REACHABLE – measured by instrumenting every Unclassifiable return: 8 hits / 2 distinct shapes across the EF10 functional suite, 28 hits / 7 shapes across the specification suite. For most of them the fall-through is correct, because the key really is rooted on the query root.

One family is not. A ThenInclude nested underneath an OWNED (embedded) hop arrives with a receiver that is itself an EF.Property hop rather than a transparent-identifier member:

Property(Property(o.Inner, "Address"), "RegionId")

That hop IS transitive, so falling through to the root tiers is exactly the EF-379 defect, and the observable symptom is silent wrong data: the Region navigation is returned as null when a matching Region row exists and should have been attached.

Measured

Orders.Include(o => o.Buyer).ThenInclude(b => b.Address).ThenInclude(a => a.Region)

Byte-identical before and after EF-379, so this is not a regression – it is a pre-existing instance of the same defect class that EF-379 did not close.

Audit correction (2026-08-07): the original write-up of this ticket characterized the symptom as "a silently null navigation under the default Native mode", which reads as Native-specific. The ticket's own measured table above shows DriverLinq reproduces the identical wrong result, not just Native. This is consistent with how the defect arises: the root/transitive classification and lookup registration happen in MongoQueryableMethodTranslatingExpressionVisitor, which builds the query expression once, upstream of the Native/DriverLinq fork (MongoQueryMode is only consulted later, by the compile-time gate) — so a wrong classification there is wrong in both modes that reach materialization. Only NativeOnly differs, because it has an explicit decline gate that the other two don't. Silent wrong data, reachable under both the default Native mode and explicit DriverLinq; loud (clean decline) only under NativeOnly.

Why it was not caught

The existing test NativeReferenceIncludeTests.A_real_ThenInclude_nested_underneath_an_embedded_hop_still_declines asserts only MongoQueryMode.NativeOnly, where the shape does decline. The EF-379 as-built note initially claimed on that basis that the provider "already declines for an unrelated pre-existing reason, so fall-through preserves that disposition exactly". That claim was measured FALSE and has been corrected in src/MongoDB.EntityFrameworkCore/Query/AGENTS.md; a NativeOnly-only assertion cannot establish a disposition for the default mode.

Fix shape

Open. ClassifyJoinHop would need to resolve a receiver that is an EF.Property chain through an owned/embedded navigation, not merely a transparent-identifier member chain. Note the classification decides WHICH SCOPE only; the FK-name tier still decides which navigation within that scope.

Beware the trap EF-379 hit: a transparent identifier is not produced only by a prior join (an owned SelectMany produces one too), so any widening here must not assume receiver shape implies join ordinal. See the withdrawn-decline record in the EF-379 note (EF-381).

Status

Unreleased path. At v10.0.2 / v9.1.2 / v8.4.2 TranslateJoin/TranslateLeftJoin/TranslateGroupJoin are all => null and TranslateSelect throws for a transparent-identifier selector, so cross-collection joins and multi-hop reference Include do not translate at all in any published package. No BREAKING-CHANGES.md entry applies.

Found during the EF-379 review (2026-08-05, branch NativeQueryOngoing, tip 9065acfc).

See also docs/superpowers/specs/2026-08-07-native-query-merge-plan-design.md §4 and docs/native-query-status-EF-322.md §9.5.