Duplicate of #29447

@roji Based on some discussions we had, this could be a place where following the relational behavior and returning null might make sense.

We could revisit this... AFAIK we simply follow the documented LINQ behavior here: Enumerable.Max throws for no elements, and the behavior here is clearly documented (source contains no elements).

A trick to do this currently without roundtrip is the following:

var max = await context.Blogs.GroupBy(b => 1).Select(g => g.Max(b => b.Id)).FirstOrDefaultAsync();

This selects out the maximum ID if there are any rows, and zero otherwise. The SQL here isn't ideal:

SELECT TOP(1) MAX([b0].[Id])
FROM (
    SELECT [b].[Id], 1 AS [Key]
    FROM [Blogs] AS [b]
) AS [b0]
GROUP BY [b0].[Key]

... but it probably doesn't actually perform differently than the simple one...

Am OK if we want to rediscuss this in design!

This is blocking me from migrating to EF Core 9

@alexandrereyes I'm not aware of a change in EF Core 9 here - which version are you upgrading from where this worked?

I don't feel strongly about it, it's just we had discussed this since the dupe issue was closed as by-design.

This is blocking me from migrating to EF Core 9

@alexandrereyes I'm not aware of a change in EF Core 9 here - which version are you upgrading from where this worked?

From Ef Core 8 with CosmosDb SQL, the difference is that EF Core 8 doesn't throw an exception if you add a (decimal?) in the instruction.
I can't use your workaround because ef core cosmosdb cannot translate the group by operation.
Using two selects to achieve this result is very inefficient....

@alexandrereyes no matter what we decide here, there won't be a change coming at least until EF 10, which is a year away (EF 9 was just released) - I hope GroupBy will be implemented for Cosmos at that point, and that it would be an acceptable workaround.

@roji This is a regression, I think that a lot of people will be impacted because it's a very basic operation

As I've asked you above, can you please explain how this is a regression? Which version of EF allowed this sort of query exactly?

On EF Core 8 Cosmos Db, the code below works:
Set<Order>().AverageAsync(a => (decimal?)a.TotalPrice)

On EF Core 9 Cosmos Db, the code below does not work, it throws sequence contains no elements exception:
Set<Order>().AverageAsync(a => (decimal?)a.TotalPrice)

On both frameworks, It should only throw the exception if I don't provide the nullable convertion, for example:
Set<Order>().AverageAsync(a => a.TotalPrice)

Apologies. I missed that this was about Cosmos specifically, and also had a mistaken idea of our behavior in relational.

@ajcvickers so it seems that in relational we actually don't throw for Min/Max/Average over the empty set, when the return value is nullable. In other words, in #29447 the user expected us to return e.g. int.MinValue for Max over non-nullable int, which we obviously don't do. But here the question is Max over nullable int.

The enumerable versions of Min/Max/Average also return null when the type is nullable, so our relational behavior is aligned with that:

int?[] ints = [];
Console.WriteLine(ints.Max() is null); // True

So I think we should indeed treat this as a regression for 8.0 and fix it... Does that sound right @ajcvickers? Can bring to design discussion if you think we need to.

await using var context = new BlogContext();
await context.Database.EnsureDeletedAsync();
await context.Database.EnsureCreatedAsync();

_ = await context.Sessions.AverageAsync(s => (int?)s.SomeInt);

public class BlogContext : DbContext
{
    public DbSet<Session> Sessions { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        => optionsBuilder
            .UseCosmos(
                "https://192.168.64.6:8081",
                "C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==",
                "Test",
                o => o.HttpClientFactory(() => new HttpClient(
                        new HttpClientHandler
                        {
                            ServerCertificateCustomValidationCallback =
                                HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
                        }))
                    .ConnectionMode(ConnectionMode.Gateway))
            .LogTo(Console.WriteLine, LogLevel.Information)
            .EnableSensitiveDataLogging();
}

public class Session
{
    public Guid Id { get; set; }
    public string PartitionKey { get; set; }

    public int SomeInt { get; set; }
}

@roji Sounds right to me.

This behavior seems to have been changed unintentionally (by me) in #34044:
https://github.com/dotnet/efcore/pull/34044/files#diff-28145bf59ab6b4afa190489d4065fc9de66e40eb4223a08e491635b217364408R538

The relevant tests are NorthwindAggregateOperatorsQueryCosmosTest.Max_no_data_nullable, Min_no_data_nullable, Average_no_data_nullable.