Ruby LSP项目中的独立模式启动问题分析与修复

问题背景

在Ruby LSP 0.9.7版本中，用户报告了一个关键问题：当项目目录中不存在Gemfile.lock文件时，语言服务器无法正常启动独立模式(standalone mode)。这个问题在0.9.6版本中表现正常，但在升级后出现了功能退化。

问题现象

当开发者打开一个没有Gemfile.lock文件的Ruby项目时，预期行为应该是：

1. 显示临时警告信息
2. 超时后自动回退到独立模式
3. 提供基本的语言服务功能

但在0.9.7版本中，实际发生的是：

1. 警告信息不再显示
2. 语言服务器完全无法启动
3. 尝试收集Ruby LSP信息时会提示"没有活动的Ruby工作区"

技术分析

通过对代码的深入检查，发现问题出在activateWorkspace和runActivation这两个核心函数的交互逻辑上：

1. 首次激活流程：

   • activateWorkspace被调用时，eager参数为true
   • 函数将激活Promise缓存到workspacesBeingLaunched映射中
   • 当检测不到Gemfile.lock时，runActivation会立即返回而不执行实际激活
   • 但Promise并未从缓存映射中移除

2. 后续激活尝试：

   • 用户打开Ruby文件时再次触发activateWorkspace调用
   • 由于缓存中仍存在未完成的Promise，直接返回该Promise
   • 导致工作区实际上永远不会被激活

解决方案

修复方案的核心思路是将Promise清理逻辑从runActivation移到activateWorkspace中，确保无论激活成功与否都能正确清理缓存：

private async activateWorkspace(
  workspaceFolder: vscode.WorkspaceFolder,
  eager: boolean
): Promise<Workspace | undefined> {
  const existingActivationPromise = this.workspacesBeingLaunched.get(
    workspaceFolder.index
  );
  if (existingActivationPromise) {
    return existingActivationPromise;
  }
  const activationPromise = this.runActivation(workspaceFolder, eager);
  this.workspacesBeingLaunched.set(workspaceFolder.index, activationPromise);
  activationPromise.finally(() => {
    this.workspacesBeingLaunched.delete(workspaceFolder.index);
  });
  return activationPromise;
}

影响范围

此问题主要影响以下场景：

• 新建的Ruby项目尚未初始化bundle
• 简单的单文件Ruby脚本开发
• 使用DevContainer等容器化开发环境

最佳实践建议

虽然此问题已在后续版本修复，但建议开发者：

1. 为每个Ruby项目初始化Gemfile，即使是最简单的项目
2. 定期更新Ruby LSP扩展以获取最新修复
3. 对于容器化开发，确保工作区路径正确配置

总结

这个案例展示了Promise缓存管理在异步编程中的重要性，特别是在语言服务器这种需要处理复杂状态的应用中。通过仔细分析执行流程和状态管理，开发团队能够快速定位并修复这个影响用户体验的关键问题。