Haskell语言服务器(HLS)中`resolve`请求处理机制优化

在Haskell语言服务器(HLS)的开发过程中，我们发现了一个关于resolve请求处理的重要问题。这类请求包括completion/resolve和codeAction/resolve等，它们用于在客户端需要时获取更详细的信息，如文档说明或非局部类型签名等。

问题背景

HLS原本的设计逻辑是：只有当某个功能项(如代码补全或代码操作)包含特别耗时的属性时，才会设置_data字段，表示该功能项支持resolve请求。然而，这种设计导致了几个实际问题：

1. 当客户端发送resolve请求但对应的_data字段为空时，HLS会直接拒绝该请求
2. 某些插件(如hls-cabal-plugin)提供的补全功能没有正确处理这种情况
3. 多个提供代码操作的插件没有实现resolve处理器
4. 特别是Vim客户端(可能也包括Emacs)会将这些拒绝请求明显地显示在用户界面中，甚至可能不应用已经存在的代码修复

技术分析

问题的核心在于HLS的resolve处理机制与客户端期望之间存在不匹配。客户端通常假设所有功能项都支持resolve请求，而实际上HLS是有选择性地支持。这种设计差异导致了不良的用户体验。

Michael Peyton Jones提出了两种可能的解决方案：

1. 宽松处理方案：如果没有任何插件想要处理resolve请求，就直接返回原始项。这种方案实现简单，但可能掩盖真正的问题。
2. 智能处理方案：通过检查_data字段的存在来判断是否"应该"处理该请求。只有设置了_data字段的项才要求必须被解析，否则可以直接返回原始项。

解决方案实现

最终采用了第二种更智能的方案，其核心逻辑是：

• 当_data字段为Nothing时，不尝试将resolve请求路由到特定插件，而是直接返回请求数据不变
• 当_data字段存在时，尝试将请求路由到相应的插件处理
• 只有当_data字段存在但无法确定处理插件时，才拒绝请求

这种处理方式与原有行为的主要区别在于对_data = Nothing情况的处理：原有实现会拒绝请求，而新方案会优雅地处理。

技术意义

这一改进具有多方面的重要意义：

1. 更好的客户端兼容性：满足了客户端对所有功能项都支持resolve的预期
2. 更优雅的错误处理：只有在确实无法处理时才返回错误，而不是因为设计差异
3. 保持灵活性：仍然允许插件为需要复杂计算的功能项实现专门的resolve处理
4. 用户体验提升：避免了客户端显示不必要的错误信息

总结

通过对HLS中resolve请求处理机制的优化，我们解决了客户端兼容性问题，提升了用户体验。这一改进展示了在语言服务器协议实现中，如何处理客户端期望与实际能力之间的差异，为类似问题提供了参考解决方案。该修复已随HLS的新版本发布，用户将能获得更稳定流畅的编程体验。