EF Querying All DbSets Randomly

[scottsauber]

For some reason, sporadically something is triggering EF to loop through and query all DbSets associated with a context and return all the results. This is causing out of memory exceptions, because it's pulling literally our entire database.

We can't seem to consistently replicate this, but when we have it's been when we call SaveChangesAsync and there's been some sort of exception (like truncation).

We are trying to trace through to figure out which call is exactly triggering this, and we're adding some additional logging to help us out and figure out the problem child. Ultimately just want to know something about where this is getting called so we can look for the root cause.

My question is - what's the trigger for EF Core to do something like this? If I know the scenario of when it happens, I can try and look at our code and see where we're hitting that scenario?

We have ClientWarnings as a throw via

optionsBuilder.ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning));

So to me this shouldn't ever happen. We get no exception or anything in the logs. A snippet of the logs as it loops through every DbSet:

[Debug] Context '"Entity1"' started tracking '"SomeDbContext"' entity. Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging' to see key values.
[Debug] Context '"Entity1"' started tracking '"SomeDbContext"' entity. Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging' to see key values.
// Repeated for every row in Entity1 table

[Debug] Context '"Entity2"' started tracking '"SomeDbContext"' entity. Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging' to see key values.
[Debug] Context '"Entity2"' started tracking '"SomeDbContext"' entity. Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging' to see key values.
// Repeated for every row in Entity2 table

// And so on through every DbSet

I suspect we have some sort of mis-config somewhere. This happens super sporadically, so I suspect we have some mis-config/data issue as every query and save has been successful thousands of times. It's just some crazy scenario we can't track down

Further technical details

EF Core version: 2.1.3
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows Server 2016
IDE: Visual Studio 2017 15.8

[ajcvickers]

@scottsauber The only thing I can think of that would cause something like this is if lazy-loading is enabled and then something tries to walk the entire graph of navigation properties. But that seems unlikely to be a randomly occurring thing, so I don't really have any good ideas.

[scottsauber]

@ajcvickers - Thanks for the quick response. I appreciate it.

We don't have Lazy Loading enabled. I've walked through all of our DbContext queries and nothing stands out to me.

This person seems to have hit something similar:
https://stackoverflow.com/questions/51510086/filtering-data-with-linq-doesnt-seem-to-compile-properly

We are using .AnyAsync in quite a few spots, where that author is using .Any but otherwise I'm at a bit of a loss of what to troubleshoot.

Is there a way to pass a Correlation ID to EF and append it as a SQL comment or something? I'd like to pass the ASP.NET Core Trace Identifier so I can trace a request from the URL all the way down to the SQL calls getting run.

[ajcvickers]

@scottsauber Query tags are available in the 2.2 preview, although they still need some work. See #1664

[divega]

@scottsauber this is just a shot in the dark, but after reading the stackoverflow.com question you pointed to, I suspect you could be seeing something like this if some code accidentally uses the LINQ extension methods for IEnumerable<T> instead of the IQueruable<T> version. This could happen if, for instance, you pass a Func<T, bool> argument instead of Expression<Func<T, bool>> to a LINQ operator that filters, like Where(), FirstOrDefault(), etc.

[scottsauber]

Appreciate the responses @ajcvickers and @divega. I will keep digging and report back what I find.

[ajcvickers]

EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it.

BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.

[scottsauber]

I can repro this on our code base... just trying to make a minimal repro now. Definitely has to do when there's a SQL exception like exceeded length/truncating and multiple saves are pending.

[rose-pace]

@scottsauber did you ever find a fix for this issue? I am having a similar problem.

[scottsauber]

@rosspace - no I did not. We still have the issue but only when there's a SQL exception which hasn't happened in the last 4 months so it hasn't been a high priority. However, I'm back to looking at this and making a small repro... but as you mention in the other issue, this has been difficult without shipping our entire codebase which isn't an option for us unfortunately.