Uvicorn 0.28.0版本中ClientDisconnected错误问题解析

在Uvicorn 0.28.0版本中，当使用FastAPI构建SSE(Server-Sent Events)流式响应时，开发者遇到了一个显著的ClientDisconnected错误问题。这个问题主要出现在两种场景中：一是当调用await request.is_disconnected()检查连接状态时，二是当处理CancelledError异常时。

问题背景

Uvicorn作为ASGI服务器，在0.28.0版本中引入了一个行为变更，导致当客户端断开连接时，不再简单地忽略该情况，而是会抛出ClientDisconnected异常。这个变更原本是为了提供更明确的错误处理机制，但却意外地影响了现有的SSE流式响应实现。

问题表现

开发者在使用FastAPI构建SSE服务时，会遇到以下两种典型场景的问题：

1. 主动检查连接状态时：当在生成器中使用await request.is_disconnected()检查客户端是否断开连接时，即使正确处理了断开逻辑，仍然会看到ClientDisconnected异常被记录。

2. 处理CancelledError时：当客户端断开连接触发CancelledError异常时，异常处理器会被正确执行，但随后仍然会看到ClientDisconnected异常被记录。

这两种情况都会导致大量错误日志被记录，尽管业务逻辑已经正确处理了连接断开的情况。

技术分析

问题的根源在于Uvicorn 0.28.0版本中改变了处理断开连接的行为。在之前的版本中，当客户端断开连接时，Uvicorn会简单地忽略这种情况。而在新版本中，它会主动抛出ClientDisconnected异常。

这个变更与Starlette的响应处理机制产生了冲突。具体来说，当Starlette尝试向已断开的连接发送响应时，Uvicorn会抛出ClientDisconnected异常，而Starlette没有妥善处理这个异常，导致它被传播到日志系统中。

解决方案

Uvicorn团队已经意识到这个问题，并在0.28.1版本中进行了修复。修复方案是回滚了导致这个问题的变更，采用了更向后兼容的策略。

对于暂时无法升级的用户，可以考虑以下临时解决方案：

1. 降级Uvicorn版本：回退到0.27.0版本可以避免这个问题。

2. 使用专门的SSE库：如sse-starlette这样的专门库已经正确处理了连接断开的情况。

3. 优化生成器逻辑：确保在检测到连接断开后立即终止生成器，避免继续尝试发送数据。

最佳实践

在处理SSE流式响应时，开发者应该：

1. 定期检查连接状态，及时终止不再需要的生成器。

2. 合理处理CancelledError等异常，确保资源被正确释放。

3. 考虑使用专门的SSE库，它们通常已经处理了各种边界情况。

4. 保持依赖库的更新，及时获取问题修复和新功能。

这个问题提醒我们，在构建流式服务时需要特别注意连接状态管理，特别是在客户端可能随时断开的情况下。良好的错误处理和资源管理是构建可靠流式服务的关键。