Changing log level of DbUpdateConcurrencyException

[dandenton]

We're in the process of updating from v6 to v7 and we're getting a lot more bloat in the logs when it comes to concurrency errors. It looks like that part of the changes for intercepting concurrency errors (which is great!) with #28315 changed that event to use the base event id of SaveChangesFailed = 10000 rather than OptimisticConcurrencyException = 10006

We've tried
options.ConfigureWarnings(w => w.Log((CoreEventId.OptimisticConcurrencyException, LogLevel.Debug)));
and
options.ConfigureWarnings(w => w.Ignore(CoreEventId.OptimisticConcurrencyException));
but it still logs as an error.

What is the recommended way of changing DbUpdateConcurrencyException logging from an error to debug? Do we really need to suppress all SaveChangesFailed errors?

[ajcvickers]

Note for triage: this looks like a bug. SaveChangesFailed is getting logged in addition to OptimisticConcurrencyException.

@dandenton I don't think there is a way to filter out only the SaveChangesFailed events that are associated with OptimisticConcurrencyException events. So I think that, until this is fixed, its a matter of living with them or changing the level of all SaveChangesFailed events.

[blackenedstrang]

Any chances to have this addressed in EF Core 7, please?
Because we've recently migrated from v5.* to v7.0.3 and started to get a lot of such errors, and our monitoring tool goes nuts because of that...

Thank you!

[dandenton]

I would note that we haven't seen any issues lowering the log level of all SaveChangesFailed errors.

builder.ConfigureWarnings(w => w.Log((CoreEventId.SaveChangesFailed, LogLevel.Debug)));

EF logs it as Debug then bubbles up the exception so we'd always end up logging it again anyway.

[blackenedstrang]

Ok, if it bubbles up the exception, then it should be fine. Thank you for the prompt answer.