Summary

A chained Join whose first hop has no model navigation cannot have its second hop's $lookup.localField scoped, because the scoping relies on finding the navigation that produced the intermediate document. Before EF-372 this silently dropped every row; after EF-372 it declines translation.

Pre-existing and depth-independent — the shape simply has no navigation for the first hop at all. Measured 2026-08-05 (EF10, real atlas-local container).

Repro

Model: {{Root

}} with no HasOne to Mid (joined manually on MidKey -> Mid.Id); Mid.Leaf navigation present.

db.NRoots.Join(db.NMids, r => r.MidKey, m => m.Id, (r, m) => new { r, m })
         .Join(db.NLeaves, x => x.m.LeafId, l => l.Id, (x, l) => x.r.Name + "|" + l.Label)
         .ToList()

One fully-linked row seeded; correct result is a single "R1|A".

• Before EF-372 (34a02067) and with EF-372's first iteration: *0 rows* — silent wrong data, the same failure mode as EF-372 itself (unscoped localField, inner $unwind drops everything).
• After EF-372: clean InvalidOperationException "... could not be translated" in both Native and DriverLinq.

Pinned by Join_chain_with_no_model_navigation_declines_rather_than_dropping_every_row in tests/MongoDB.EntityFrameworkCore.FunctionalTests/Query/Ef372DeepReferenceIncludeTests.cs, so it cannot silently regress to dropping rows.

Root cause

TryResolveIntermediateLookupPrefix (src/MongoDB.EntityFrameworkCore/Query/Visitors/MongoQueryableMethodTranslatingExpressionVisitor.cs) resolves the prefix for a transitive hop by identifying the navigation that produced the intermediate — tier 1 from the pending lookups, tier 2 from what a prior join recorded in the outer query's projection. Neither can succeed when the first hop is a bare key-equality Join with no navigation in the model, so the resolver declines.

EF-372 deliberately converted the unresolvable case from "emit a root-relative localField" (silent wrong data) to "decline", which is why the symptom changed. Turning the decline into correct rows is this ticket's work and was explicitly out of EF-372's scope.

Fix shape

Open. Scoping a transitive hop without a navigation to anchor on needs a different source of truth than the navigation graph — most likely the structural position of the prior join's output in the pipeline rather than its navigation. Worth assessing against EF-376 (path-scoped aliases), which touches the same area.

Status

Unreleased: the native transitive-join path postdates v10.0.2 / v9.1.2 / v8.4.2, arriving with efb5f256 (EF-117). At those tags any cross-collection Join throws, so no shipped behavior is affected.

Priority note: the current disposition is a loud failure rather than wrong data, so this is a functionality gap, not a correctness risk.