-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase of exceptions thrown after upgrading to .NET 7 and Microsoft.Data.SqlClient 5.0.1 #1933
Comments
have you tried 5.1.0 (unclear from your post) ? |
No, only preview2. I plan to test 5.1.0 but from what I can tell 5.1.0 doesn't seem to address anything (compared to preview2) that could be related to this problem. Another one in the issue over at DistributedLock tested 5.1.0 with no luck. |
Do you mean this is happening when you target Azure SQL DB? If yes, a minimal repro still would be a very helpful asset to address the source of the problem. |
For me, yes. I never have workers (where we see the issue) running locally for long enough to know if I would have the same issue locally. @hoerup though have seen similar issues using an on-prem SQL Server (see this comment).
I will do my best to replicate the issue in a repo and environment that I can share. I will need a few days, at least, though. Since my last comment last week I upgraded some services to use 5.1.0 but unfortunately that made no difference. |
I just got a repo together that hopefully will reproduce the error. I tried to create a new env that looks as similar as possible to one where we seen this issue. I just moved big chunks of code that might be relavant from our code base to a new project and made it compile again. It looks horrible... I'll check back on the logs in a few days and see if it seems to work. Or rather not work :) The repo is here if anyone is interested: https://github.com/OskarKlintrot/Rebug |
Any luck with the repo @OskarKlintrot ? |
Maybe this is the cancellation token issue. Try 5.0.2 |
Unfortunately it's rock solid when I try to repo it. Not sure why, we do have some load on our databases in the test env but it's very little. I wonder if I can create an artificial load on the db some how and see if that makes a difference. I've seem some of the issues in #1527 in our environments but I haven't seen them either.
I'm using |
I mean 5.0.2 or 5.1.1 |
I'm not following, is there something in 5.0.2 and 5.1.1 that's not in 5.1.0? |
Yes |
I forgot to test |
some older versions are still maintained and 5.0.2 was released after 5.1.0 |
@OskarKlintrot any luck with 5.1.1? |
@madelson I don't think so but I'm seeing something else that's very weird. We had daily exceptions in April until 28:th. That's when I moved all our databases in our test env to a single elastic pool. After that we only had exceptions in May 1:st, 12:th and 15:th. Unfortunately, we hade a bunch the 15:th after I deployed 5.1.1. So now it seems to be much harder to replicate reliably in our test environments but it still doesn't seem to work properly. |
This seems to be fixed now in later versions (unsure exactly which since it gets upgraded as a transitive dependency to EF Core). I just run my query from the top and don't get anywhere near the numbers in the original post. The small amount that is left seem realistic to be from "naturally occurrent events", such as shutting down of old services after deploying new versions, intermittent network and/or database issues etc. |
Describe the bug
We've seen a dramatic increase of exceptions thrown after upgrading to .NET 7 and EF Core 7. EF Core 7 uses Microsoft.Data.SqlClient (>= 5.0.1) but EF Core 6 used Microsoft.Data.SqlClient (>= 2.1.4). We had an explicit dependency on 4.1.0 though.
We started upgrading our services before Christmas and around the same time the amount of exceptions started to increase from a few a month to 10-50 on some days.
The only change we have done that we figure might have an impact is upgrading from .NET 6 to .NET 7 and Microsoft.Data.SqlClient from 4.1.0 to 5.0.1.
We first noticed this because DistributedLock.SqlServer started to drop locks. After some back and forth in that issue I realized that I had accidently suppressed all exceptions from when the lock was lost. When logging the exceptions they all came from
Microsoft.Data.SqlClient
. We also got some exceptions from EF Core so it doesn't seemt to be specific to DistributedLock.SqlServer. In that issue another user had the same issue but they use SQL Server on-prem while we use Azure SQL. So the only common nominator between all issues and exceptions seems to be Microsoft.Data.SqlClient.This issue seems to be similar, but not identical, to #1527.
Exception from DistributedLock.SqlServer
Exception from DistributedLock.SqlServer
I don't seem to be able to find a (relevant) exception from EF Core, unfortunately.
To reproduce
Not sure how to replicate since it only occurs on Azure and not during local development.
Expected behavior
Don't throw any more exceptions than previous versions.
Further technical details
Microsoft.Data.SqlClient version: 5.0.1, 5.1.0-preview
.NET target: .NET 7
SQL Server version: Azure SQL (in my case, see also this issue)
Operating system: Azure App Service, seems to be Windows 2016
Additional context
The chart is for 90 days back, counting from 2023-02-24.
The text was updated successfully, but these errors were encountered: