Strawberry GraphQL订阅功能内存泄漏问题分析与解决方案

在Strawberry GraphQL框架的0.240.0版本中，引入了一个关于WebSocket订阅功能的重要回归问题。当WebSocket连接异常中断时，订阅协程无法正常结束，导致内存泄漏。这个问题在客户端正常关闭连接或订阅自然结束时不会出现，但在连接意外中断时表现得尤为明显。

问题现象

通过一个简单的测试用例可以清晰地重现这个问题。测试场景包含：

1. 服务端实现一个GraphQL订阅接口，该接口会在5秒后返回结果
2. 客户端建立WebSocket连接后，在2秒时被强制终止
3. 服务端记录活跃订阅数量

在0.240.0及以上版本中，当客户端异常断开时，服务端的订阅协程不会执行finally块中的清理代码，导致活跃订阅计数不断增加。而在0.239.2版本中，无论连接如何中断，finally块都能正常执行。

技术分析

这个问题源于对WebSocket协议处理逻辑的修改。具体表现为：

1. 当客户端异常断开时，服务端尝试发送数据消息会抛出RuntimeError
2. 这个异常没有被正确处理，导致订阅协程被静默终止
3. 协程的finally块和清理逻辑因此无法执行

值得注意的是，这个问题仅影响基于graphql-ws协议的实现，而graphql-transport-ws协议不受影响。这是因为两种协议对连接中断的处理机制不同。

影响范围

该问题影响所有0.240.0及以上版本的Strawberry GraphQL框架。对于依赖长时间订阅服务的应用，特别是那些可能面临不稳定网络环境的部署场景，这个问题可能导致严重的内存泄漏，最终影响服务稳定性。

解决方案

对于遇到此问题的用户，可以考虑以下临时解决方案：

1. 降级到0.239.2版本
2. 改用graphql-transport-ws协议
3. 在应用层实现额外的连接健康检查机制

框架开发者应当修复WebSocket异常处理逻辑，确保在任何连接中断情况下都能正确清理订阅资源。修复方向包括：

1. 增强异常捕获范围
2. 实现更健壮的协程生命周期管理
3. 添加资源泄漏检测机制

最佳实践

为了避免类似问题，建议开发者在实现GraphQL订阅时：

1. 总是使用try-finally块管理资源
2. 实现连接超时机制
3. 监控活跃订阅数量
4. 在生产环境部署前进行充分的异常场景测试

对于Strawberry GraphQL用户，建议密切关注该问题的修复进展，并在升级版本时特别注意订阅功能的相关变更说明。