[CaffeinatedCoder]

Refs #349
Refs #350
Closes #351

Problem

#349 and #350 were found by a consumer's differential probe (AuditOffice, 2026-10-23), not by an oracle here. Nothing in ExecutedQueryTests compared LowerBound() or UpperBound() with null inside a query, nothing ran a range predicate over a nullable range column, and no claim quoted the docs/efcore.md sentence #349 contradicts. So neither fix would be proven by the suite, and nothing would force the registry entries out when the fixes land. These are candidates, not fixes, which is why the PR refers to #349 and #350 rather than closing them; it closes its own tracking issue, #351.

Change

• ExecutedQueryTests.BoundsComparedWithNull_SelectTheRowsMemorySelects (LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349) seeds nine shapes ([a,b], [a,a], [b,b], (,a], (,b], [a,), [b,), (,), empty) into 13 range columns: Seats, Tickets, Price, Period, LocalTime, InstantTime, NodaPeriod, NodaWallClock, NodaWindow, OpeningHours, Score, Load and BillingPeriod. Over them it runs LowerBound() == null, LowerBound() != null, LowerBound().HasValue, UpperBound() == null, UpperBound() != null, (UpperBound() ?? max) >= v, (LowerBound() ?? min) <= v, Select(UpperBound() ?? max) and Select(new { Id, To = UpperBound() }).Where(To == null). Each runs on the server and as LINQ over the rows as loaded. The operation is written once over IRange<T> and spliced onto the column (FuzzEngine.Splice), so the call is the one r.Column.LowerBound() makes. Operands are captured, so they go out as parameters. Each failure line starts with the operation, then the column.
• ExecutedQueryTests.PredicatesOverANullableColumn_SelectTheRowsMemorySelects (A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350) puts a nullable DateRange column, holding NULL and six shapes, in a database of its own, following the RangeOrderParityTests pattern. Over it it runs the twelve predicates of the issue: !IsEmpty(), !IsFinite(), !IsUnboundedEnd(), !UpperBoundInclusive(), !Overlaps(p), Contains(Empty), IsContainedBy(Infinite), Intersect(p) != null, Intersect(p) == Empty, Gap(Empty).IsEmpty(), Union(Infinite).Contains(v) and Merge(Infinite) == x. A row whose in-memory evaluation throws is left out on both sides. Lines are one per row, so each candidate quarantines only the NULL row and the six non-null rows stay judged.
• test/oracles/candidates.json gets 21 entries, one per operation, scoped by method. Nine belong to LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349, family "lower()/upper() declared NULL only for a NULL argument", with rows like LowerBound() == null on . Twelve belong to A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350, family "a null receiver answers in memory where SQL answers NULL", with rows like !IsEmpty() on DateRange? null:.
• test/oracles/claims.json gets E70-bounds-null-for-unbounded-or-empty-in-sql, which quotes "LowerBound() and UpperBound() return T?. PostgreSQL's lower and upper return NULL for an unbounded or empty range, and the in-memory methods match that." (docs/efcore.md#read-bounds-merge-ranges-and-aggregate). It is held by ExecutedQueryTests.

Tests

All runs were local against Docker on SDK 11.0.100-rc.2.26504.105, with ExecutedQueryTests run as a class.

• Before registering: both new tests fail. That is 117 lines for LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349, every operation on every column with one identical outcome per operation across all 13 columns, and 12 lines for A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350, where only the NULL row ever differs.
• Held (postgres:16-alpine and postgres:18-alpine): 15/15 pass, with 117 SKIPPED [known candidate: …, #349] and 12 SKIPPED [known candidate: …, #350] lines.
• LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349's issue blanked: the bound sweep fails with its rows labelled [known candidate: lower()/upper() declared NULL only for a NULL argument], while A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350's 12 stay skipped.
• A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350's issue blanked: 12 rows fail labelled [known candidate: a null receiver answers in memory where SQL answers NULL], while LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349's 117 stay skipped.
• LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349's fix applied locally (argumentsPropagateNullability: [false] in BoundFunction, ValueRangesMethodCallTranslator.cs:639): the bound sweep fails with exactly the nine candidate fixed: remove the entry … lines and no other row. All 117 operation-column pairs now agree, A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350's 12 stay skipped, and the other 13 tests pass. The fix was reverted; it belongs in its own PR, which removes the nine LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349 entries.
• dotnet run tools/oracles.cs status: 25 candidates, 0 without an issue, and E70 held.
• Conventions: Oracle*Tests plus SeedVerdictTests pass 36/36.

Not covered here:

• RangeSet's LowerBound()/UpperBound() go through the same helper (LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349 says so), but are not swept.
• A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350 is swept over one type.
• While LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349 is open, its candidates cover every row of their operation, so the bound sweep adds no protection until the fix lands.
• The release/10.x port is left for later.

🤖 Generated with Claude Code