GraphQL-WS 项目中WebSocket关闭后订阅未清理问题解析

在GraphQL-WS项目使用过程中，我们发现了一个关于WebSocket连接关闭后订阅资源未正确释放的问题。这个问题可能导致服务器端内存泄漏和资源浪费，值得开发者重视。

问题现象

当客户端通过WebSocket建立GraphQL订阅后，如果客户端突然断开连接（如直接关闭浏览器标签），服务器端在某些情况下无法正确清理已建立的订阅资源。具体表现为：

1. 订阅的异步迭代器(AsyncIterable)的return方法未被调用
2. 订阅资源持续占用内存
3. 服务器端可能积累大量无效订阅

问题根源

深入分析问题，我们发现其核心原因在于订阅处理的时序问题：

1. 当客户端发起订阅请求时，服务器会调用对应的subscribe解析器
2. 在解析器返回Promise期间，如果客户端突然断开连接
3. 服务器虽然会触发WebSocket的close事件处理
4. 但此时订阅Promise可能尚未完成解析
5. 导致订阅成功后被错误地保留在服务器内存中

技术细节

从实现层面看，问题出在订阅管理逻辑上：

1. 服务器使用ctx.subscriptions对象管理活跃订阅
2. 订阅Promise解析后才将其加入管理集合
3. 如果在此期间连接关闭，清理逻辑无法捕获这个"半成品"订阅
4. 最终导致订阅既不会被使用，也不会被清理

解决方案

该问题已在5.15.0版本中修复，主要改进包括：

1. 增强订阅状态跟踪机制
2. 确保在任何情况下连接关闭时都能正确清理资源
3. 优化订阅Promise的处理流程
4. 添加了更完善的错误边界处理

开发者建议

对于使用GraphQL-WS的开发者，建议：

1. 及时升级到5.15.0或更高版本
2. 在自定义订阅解析器中实现资源清理逻辑
3. 考虑添加监控机制跟踪活跃订阅数量
4. 对于关键资源，实现双重清理机制

总结

WebSocket连接管理是实时应用中的关键环节，这次问题的修复提升了GraphQL-WS在异常情况下的健壮性。开发者应当理解订阅生命周期管理的重要性，确保应用在各种网络条件下都能正确释放资源。