Infinite register of language feature

[AkatQuas]

What version of VS Code are you using?

Version: 1.98.2
Commit: ddc367ed5c8936efe395cffeec279b04ffd7db78
Date: 2025-03-12T13:32:45.399Z
Electron: 34.2.0
ElectronBuildId: 11161602
Chromium: 132.0.6834.196
Node.js: 20.18.2
V8: 13.2.152.36-electron.0
OS: Darwin arm64 23.6.0

What version of Tailwind CSS IntelliSense are you using?

v0.14.15

What version of Tailwind CSS are you using?

For example: v2.0.4

What package manager are you using?

pnpm

What operating system are you using?

macOS

Tailwind config

Private config.

VS Code settings

{
  "tailwindCSS.includeLanguages": {
    "ttml": "html"
  }
}

Reproduction URL

Private project.

Describe your issue

Infinite register of language feature. Don't know what triggers this.
It has been 3 weeks since report from my colleagues.

[thecrypticace]

@AkatQuas Huh this is odd. I don't think I've seen anything like this. I assume this may be some kind of issue with our language server but I'm not sure.

1. Are you debugging the vscode extension host itself?
2. How did you or others notice this behavior?
3. Does this happen with all other extensions disabled in the same project?
4. Can you trace the languages to/from the language client and see if there's a pattern? (can use the tailwindcss-intellisense.trace.server setting for this)

[AkatQuas]

My project is a huge pnpm workspace with 500 sub projects, most of them has one tailwind.config.js, does this would trigger multiple language client initialization?

I cloned the repository and start the extension debug procedure, it can be reproduced when switching quickly between two files (ts files in my case) from different sub projects.

On the output channel in the left, language client sent bunch of documentLink request and then the process starts consuming lots of cpu and stucked.

[thecrypticace]

Having multiple projects could cause capability registration to happen multiple times but it's not supposed to happen a lot. Basically what we do is take the data from all registered projects and figure out what they can do and then register some additional information based on that.

We should ba able to simplify at least some of those but for v0–v3 projects completion requests have to be registered dynamically b/c you can change the variant separator. (we just happen to register some more dynamically as well but these could be moved).

Lemme look into this some and see what I can come up with. Thanks for the info!

[AkatQuas]

Another observation, this extension would handle autocompletion for many languageId files. So I use the exclude configuration to reduce since our project only use the feature in XML files.

This might help to reduce the invocation. What a relief for my cpu, 😄

[thecrypticace]

Yeah, the extension does handle lots of language IDs because people use Tailwind CSS across lots of different projects so we have to handle a bunch of different file types.

I've got a possible fix in #1327 — if you test that on your project does the behavior improve?

[AkatQuas]

It seems #1327 works perfectly when switching files among projects.

Not a chance to reproduce cpu stuck with this fix.

Thanks !

[thecrypticace]

@AkatQuas fantastic. I realized I made a small mistake in that PR after verifying behavior with some tests.

It shouldn't affect the behavior significantly but if you wouldn't mind giving it one more test I'd really appreciate it. Thanks!

[AkatQuas]

Sorry for the delay.

I can't even notice such refactor changes for this problem. I thinks it's a GO for #1327 .

The stuck can occur easily in the main branch, indeed.