从 .NET Core 2.2 迁移到 3.1 后，EF Core 随机抓取 API 请求上的用户表

Posted 2023-03-29

【中文标题】从 .NET Core 2.2 迁移到 3.1 后，EF Core 随机抓取 API 请求上的用户表

【英文标题】：EF Core randomly crawls user tables on API requests after migrating from .NET Core 2.2 to 3.1

【发布时间】：2021-12-30 03:42:02

【问题描述】：

从 .NET Core 2.2 迁移到 3.1 后，EF Core 会随机开始爬取用户表并生成成百上千的日志（见图 - 具体日志在底部以蓝色突出显示）。

我已遵循 Microsoft 的迁移指南，例如2.2 到 3.0 和 3.0 到 3.1。 （例如：https://docs.microsoft.com/da-dk/aspnet/core/migration/22-to-30?view=aspnetcore-2.1&tabs=visual-studio）。

重要信息：这已经开始发生之后我在Startup.cs 中添加了app.UseAuthorization();，这是以前没有的。

有什么想法可以触发这个吗？

大约 30 秒后会导致以下错误：504 Gateway Time-out

我正在使用 NuGet AspNet.Security.OpenIdConnect.Server。

更新似乎发生在Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException: Database operation expected to affect 1 row(s) but actually affected 0 row(s). 所以根除该异常应该可以修复它，但我会非常小心地将此迁移推送到生产服务器，如果某种异常可能导致 EF Core开始无休止地爬行。

【问题讨论】：

它与 EF Core 无关。其他一些代码（例如来自授权管道）正在生成对 EF Core 的调用，这当然会执行它所请求的操作。

@IvanStoev 经过更多研究，在代码抛出DbUpdateConcurrencyException 之后，它似乎开始发生了@

@IvanStoev 如果您有兴趣，问题出在使用 Serilog 记录异常时将destructureObjects 设置为 true，出于某种原因。所以当一个异常在try-catch 中被捕获并被记录下来，它就开始无休止地爬行。

它只是证明问题不是来自/与 EF Core，而是其他代码/库（正如我在上一条评论中所写）。

@IvanStoev 当然，这只是为了通知您，如果您对根本原因感兴趣。

【参考方案1】：

问题出在使用 Serilog 记录异常时，由于某种原因，destructureObjects 设置为 true。因此，当try-catch 中捕获到异常，然后将destructureObjects 设置为true 进行记录时，它开始无休止地爬行。

【讨论】：

无休止字面意思还是比喻意思？我相信有一个可控的最大深度。 IIRC 最近有所减少。 （并为自我回答 +1）

@RubenBartelink 主要是比喻性的，但每次它发生时我们都会手动停止它（可能在我们这样做之前最多一两分钟）。如果您知道其他情况或类似情况，我肯定有兴趣阅读更多关于此或可能导致它的原因。我们没有设置最大深度，但使用 DestructuringPolicy 明确解决了异常，因为它们是导致问题的原因。