为何Npgsql在超时场景下抛出两种不同类型的异常？

我正在使用EF Core开发ASP.NET Core Web API，并实现了如下所示的超时中间件：

public async Task InvokeAsync(HttpContext context, RequestDelegate next)
{
    int commandTimeoutInSeconds;

    if (context.Request.Path.StartsWithSegments("/shorterTimeout"))
    {
        commandTimeoutInSeconds = _appConfig.shorterTimeout;
    }
    else
    {
        var conn = new NpgsqlConnectionStringBuilder(_appConfig.ConnectionString);

        if (conn.TryGetValue("Command Timeout", out object? commandTimeout))
        {
            commandTimeoutInSeconds = Convert.ToInt32(commandTimeout);
        }
        else
        {
            // assume a default of 30
            commandTimeoutInSeconds = defaultCommandTimeoutInSeconds;
        }
    }

    var dbContext = context.RequestServices.GetRequiredService<ApplicationContext>();

    dbContext.Database.SetCommandTimeout(commandTimeoutInSeconds);

    await next(context);
}

该中间件看似工作正常，API路由会按预期超时，但部分路由直接抛出提示“Timeout during reading attempt”的NpgsqlException，而其他路由则抛出InvalidOperationException: an exception has been raised that is likely due to a transient failure，且前者作为后者的内部异常。

我尝试调整触发异常的查询以查看复杂度是否有影响，但未发现关联；也排查了EF Core是否自动重试查询，代码库中未启用该行为，且默认也不开启。请问这一现象的原因是什么？

分析与解答 #

两种异常的本质区别 #

• NpgsqlException: Timeout during reading attempt：这是Npgsql驱动层面直接抛出的底层异常，当驱动在等待数据库返回查询结果的过程中，超过了设置的CommandTimeout阈值时触发，属于直接的读取超时。
• InvalidOperationException: An exception has been raised that is likely due to a transient failure：这是EF Core对底层异常的包装，只有当EF Core判定当前异常属于「瞬态故障」范畴时，才会抛出这个包装异常，原始的NpgsqlException会作为内部异常存在。

出现差异的核心原因 #

1. EF Core的瞬态故障判定逻辑
   EF Core内部有一套异常分类规则，会将部分数据库异常标记为瞬态故障（比如连接超时、临时网络波动）。但Npgsql的「读取超时」是否被判定为瞬态故障，取决于EF Core与Npgsql驱动的版本匹配，以及异常触发的具体阶段：

   • 如果超时发生在数据库连接建立阶段，EF Core更可能将其归类为瞬态故障；
   • 如果超时发生在查询执行后的结果读取阶段，Npgsql直接抛出读取超时，EF Core可能不会将其标记为瞬态故障，直接抛出原始异常。

2. DbContext实例的作用域问题
   你的中间件从请求服务容器中获取ApplicationContext，但如果某些路由在中间件执行之前，就已经有其他组件（比如过滤器、自定义服务）解析了DbContext实例，那么你设置的超时值就不会应用到实际执行查询的DbContext上。此时这些查询可能使用了连接字符串中的默认超时，触发不同的异常包装逻辑。

3. 查询执行方式的差异
   不同路由的查询执行方式可能存在差异，导致异常表现不同：

   • 同步查询（如.ToList()）和异步查询（如.ToListAsync()）的超时处理逻辑在Npgsql驱动中有细微区别，抛出的异常类型可能不同；
   • 部分查询可能涉及多阶段命令执行（比如批量操作、延迟加载触发的额外查询），不同阶段的超时触发时机不同，也会导致异常包装的差异。

验证与解决建议 #

• 确认DbContext实例一致性：在中间件和Controller中打印DbContext的GetHashCode()值，确保设置超时的实例和执行查询的实例是同一个，避免因作用域问题导致超时设置失效。
• 统一异常处理逻辑：在全局异常过滤器中捕获NpgsqlException，根据异常消息判断是否为超时，统一处理；同时检查DbContextOptions配置，确认未意外启用瞬态故障检测（即使未显式配置，部分版本的EF Core可能默认对特定Npgsql异常启用该逻辑）。
• 统一查询执行方式：尽量使用异步查询方法（符合ASP.NET Core最佳实践），减少同步/异步操作带来的超时处理差异。

内容的提问来源于stack exchange，提问作者radoll