Extra semanticTokens requests in a multiroot workspace

[andyw8]

👋

I'm a maintainer on Ruby LSP.

I have a multiroot repo with two apps, app1 and app2. https://github.com/andyw8/multiroot_monorepo

While a file from app1 is open, the logs show all requests going to app1, as expected, except for one type of request, semanticTokens:

This happens even if I have no files from app2 open.

Is there something special about semanticTokens that might cause it to behave that way?

(I can provide further information to help troubleshoot, but wanted to ask this up-front in case there's a simple answer).

cc @vinistock

[vinistock]

Worth pointing out that the Ruby LSP spawns separate language servers for each configured workspace. Each one of the clients has their document selector configured to only handle requests for the specific workspace they are related to.

All other requests work as expected: each language server only receives requests for files that are inside their workspace. Except for semantic highlighting, which seems to be sent to all servers despite the document selector.

[dbaeumer]

Is this still an issue? If so, what document selectors are you using for the different workspace folders?

[vinistock]

Yes, it still happens. In fact, we started noticing that code snippets in Copilot Chat also trigger a semantic highlighting request before ever sending a textDocument/didOpen notification. It kept erroring for us because the server wasn't aware of that document's existence.

Just recently, we tried to limit our document selector to only the file and git schemes (PR), but we still see the Copilot Chat window firing semantic highlighting requests.

Our document selector is configured like this (simplified):

const selector = [
  // Selectors for documents inside the workspace for `ruby` and `erb`
  { scheme: "file", language: "ruby", pattern: `${workspaceFolder.uri.fsPath}/**/*` },
  { scheme: "git", language: "ruby", pattern: `${workspaceFolder.uri.fsPath}/**/*` },
  { scheme: "file", language: "erb", pattern: `${workspaceFolder.uri.fsPath}/**/*` },
  { scheme: "git", language: "erb", pattern: `${workspaceFolder.uri.fsPath}/**/*` },

  // Selectors for unsaved files
  { scheme: "untitled", language: "ruby" },
  { scheme: "untitled", language: "erb" },

  // Selectors for bundled gem dependencies
  { scheme: "file", language: "ruby", pattern: `${home}/.gem/ruby/${rubyVersion}/gems/**/*` },

  // Selectors for default gem dependencies
  { scheme: "file", language: "ruby", pattern: `${home}/.rubies/${rubyVersion}/lib/gems/**/*` },
]

Each workspace can have its own set of dependencies and it's possible to configure their installation path completely differently. For example, you can have a workspace that installs all dependencies under ~/.gem and another one that installs inside the workspace under vendor/bundle.

However, we see these extra semantic highlighting requests for files inside the workspaces or for the Copilot Chat snippets, not for files in dependencies.

[dbaeumer]

Regarding textDocument/didOpen and request: according to the spec it is legal to send requests for documents that are not open. Open is a bad name since it is more about ownership.

I will look into why the sematic color request is not scoped correctly

[dbaeumer]

I tried to reproduce this but failed. Can you check in semanticTokens.js around here:

that this is called twice with different document selectors. Can you also let me know how these selectors look like.