Absinthe GraphQL 重复订阅问题解析与解决方案

问题背景

在 GraphQL 订阅场景中，有时我们需要对同一个订阅主题建立多个订阅连接。例如，一个应用可能需要：

1. 长期存在的通知计数器订阅
2. 仅在通知内容组件打开时才存在的详细通知订阅

理想情况下，这两个订阅应该能够独立存在和销毁。然而，在 Absinthe 1.7.6 版本中，当取消其中一个订阅时，会导致另一个订阅也被意外终止。

技术原理

Absinthe 的订阅机制内部使用注册表(Registry)来管理订阅关系。当客户端订阅时，系统会生成一个唯一的文档ID(doc_id)和字段键(field_key)来标识订阅。问题出在取消订阅时的处理逻辑上。

问题根源

当前实现中，取消订阅时会根据 field_key 完全移除注册表中的所有相关记录。当两个订阅共享相同的 field_key 时（即使它们有不同的 doc_id 和字段选择集），取消其中一个订阅会导致另一个订阅也被移除。

关键问题代码位于订阅模块中，它直接通过 field_key 进行反注册操作，而没有考虑 doc_id 的差异。

解决方案

正确的实现应该是：

1. 在取消订阅时，仅移除与特定 doc_id 关联的订阅记录
2. 保留其他 doc_id 的同 field_key 订阅
3. 只有当某个 field_key 的所有 doc_id 都被取消时，才完全清理该订阅主题

这种改进确保了订阅的独立性，使得多个客户端或同一客户端的多个组件可以安全地订阅相同的主题而不会相互干扰。

实现建议

对于使用 Absinthe 的开发者，建议：

1. 升级到修复此问题的版本
2. 如果暂时无法升级，可以考虑为不同的订阅用途添加区分参数
3. 在客户端实现重连逻辑作为临时解决方案

对于库维护者，修复方向是修改反注册逻辑，使其基于 field_key 和 doc_id 的组合来精确移除订阅记录。

总结

订阅机制是 GraphQL 的重要特性，正确处理多个订阅场景对于构建实时应用至关重要。Absinthe 的这个修复确保了订阅系统的健壮性和灵活性，使开发者能够更自由地设计他们的实时数据流架构。