[CaffeinatedCoder]

Closes #452

Cherry-pick (-x) of #453 into release/10.x, for 10.3.0. Closes doesn't act on a release branch, so #452 is closed by hand once both PRs merge.

Problem

#385 keeps a range comparer's Compare out of SQL, but it decided by the parameter type Compare declares. A comparer declared over IRange<T>, the non-generic System.Collections.IComparer (including Comparer<DateRange>.Create(…) held as one) and any comparer of value sets declare a type RangeTypeRegistry doesn't hold, so EF Core still read the call as the natural order. With p = [2026-03-01,2026-03-10], Where(r => cmp.Compare(r.Period, p) == 0) became WHERE r."Period" = @p and returned one row where memory returns three. The changelog row, docs/efcore.md#what-runs-where and the migration guide all promise that every IComparer of ranges or sets fails translation.

Change

• ValueRangesQueryExpressionInterceptor.RangeComparerRewriter: rewrites when either operand is a range, range set or value set. It checks the operand itself and each conversion on its way to the declared type, and reaches a sealed variant through its union. The comparer must still implement IComparer<TDeclared> or, for Compare(object, object), the non-generic IComparer.
• RangeComparerCall: a RunInMemory(IComparer, object?, object?) overload with the same name, so EF's error message still shows RangeComparerCall.RunInMemory.
• docs/efcore.md (What runs where) and docs/migration.md (Move RangeLowerBoundComparer out of queries) name the three kinds. Claim E31 says the operands decide.
• CHANGELOG.md and the EF Core changelog: 10.x: RangeLowerBoundComparer.Compare in a query runs in the range order (port of #385) #396's ### Changed answers row now says "whatever type it is declared over" and links A comparer of ranges or sets declared over IRange<T>, the non-generic IComparer or a value set still compares in the range order in SQL #452, as pr-hygiene.sh requires for a silent PR into a minor.

Tests

• ClientSideOnlyTranslationTests: Where and OrderBy rows for an IComparer<IRange<DateOnly>>, a non-generic IComparer and an IComparer<StringSet>.
• LowerBoundComparerQueryTests (live PostgreSQL 16; reverted and proven on main, fix: keep a comparer out of SQL by what it compares, not its declared type (#452) #453): the same comparers, plus Comparer<DateRange>.Create as IComparer and a comparer class of our own. Each fails translation in Where and OrderBy with RangeComparerCall.RunInMemory in the message. In a final Select each gives memory's answer; for value sets the test adds a Tags column and compares by count against {z}.
• Reverted: with the old declared-type check put back, the six new translation rows fail, the live filter query returns rows instead of throwing, and the projection reads the NULL row's Compare from SQL. That proves the tests catch the bug.
• A trap the tests avoid: a comparer held in a static readonly field reaches EF as a constant, and EF never translates Compare on a constant, so those rows fail with or without the fix. The comparers in both tests are captured locals, so they become query parameters, which is the case the review reproduced.
• On .NET 10 SDK 10.0.402: EF unit tests (342), the conventions tests (420), and TranslationSupportProbeTests, CapturedCollectionProbeTests, ClientSideOnlyProjectionTests and LowerBoundComparerQueryTests live all pass. The seed lower-bound-comparer-runs-as-sql.patch still applies.

🤖 Generated with Claude Code