Unnecessary "Couldn't connect to GDScript language server" when in non-Godot workspace

[Gaiko-sw]

Godot version

4.2.2 stable

VS Code version

1.89.1

Godot Tools VS Code extension version

2.1.0

System information

Ubuntu 24.04

Issue description

When opening a non-Godot workspace in VSCode, the Godot extension still generates a notification that "the GDScript language server isn't available", even though it isn't necessary.

The notification should still pop up if it's detected that this workspace is a Godot project.

Steps to reproduce

• Don't have Godot opened
• Open a random, not-Godot workspace
• Wait about a minute
• Note the warning notification in the bottom-right, "Couldn't connect to the GDScript language server at 127.0.0.1:6008. Is the Godot editor or language server running?"

[DaelonSuzuka]

The extension should only be activated if you open a Godot file or if it find a project.godot in the workspace. Do you have any tabs open from the previous workspace with .tscn, .gdscript, .tres, .res, .import, or .gdshader files? (this list is from memory and may not be exactly correct)

[Calinou]

I think opening a .gd file in a workspace that lacks a project.godot file shouldn't attempt connecting to a LSP, but this is prone to false negatives if your workspace root is a subfolder of the project root.

[Gaiko-sw]

At the moment I think opening a Godot project first and then opening a (non-Godot) C# project straight after might trigger it, and then again even if you close and reopen Code.

Do .cs files trigger the extension? Is it possible that they only trigger it with a project.godot file, and the extension hasn't realised I've changed to a non-Godot C# project?

I thought it also happened in other workspaces but I can't reproduce it now.

[DaelonSuzuka]

Are you using the Godot C# extension also?

[ParadoxV5]

“Copy Resource Path” option appears in the right click menu of tabs in non-Godot project files as well.
(Mis)clicking it easily raises “Current workspace is not a Godot project” and/or “Couldn't connect to GDScript language server”.

[Gaiko-sw]

Are you using the Godot C# extension also?

Nope.
I've just tested that I get the popup in a totally empty directory, and the notification says Source: godot-tools

[DaelonSuzuka]

The only things that are supposed to activate this extension are:

• the workspace contains project.godot
• a godot-flavored debug session gets started
• opening a file that resolves to one of the contributed languages:
  • .gd
  • .tscn
  • .godot
  • .tres
  • .import
  • .gdns
  • .gdnlib
  • .gdshader
  • .gdshaderinc

The activation events listed in package.json:

"activationEvents": [
	"workspaceContains:project.godot",
	"onDebugResolve:godot"
],

I have absolutely no explanation for this extension getting activated for any reason outside the ones listed here.

[digitalhobbit]

I'm seeing the same issue. When I open any non-Godot VSCode project, it still attempts to connect to Godot and eventually pops up the error message.

[digitalhobbit]

Another data point that might be related: In addition to the GDScript button and connection warning in the lower right, I also see the "Godot Tools: Scene Preview" section in the left nav. I assume that this is also supposed to only show up when a Godot project is detected. So it seems like the Godot project detection might have a bug that's resulting in a false positive.

[DaelonSuzuka]

The Scene Preview section actually isn't a bug: I personally hate it when major UI elements like that appear and disappear. It's much easier on my muscle memory if the action bar always has the same sections in the same order.

I recently merged a significant refactor of the LSP Client internals, and one of the downstream goals of that is redoing the entire client connection workflow to be as hands-off as possible. The LSP status bar widget is probably going to go away as a result of this, along with the "couldn't connect" message.

[digitalhobbit]

The Scene Preview section actually isn't a bug: I personally hate it when major UI elements like that appear and disappear. It's much easier on my muscle memory if the action bar always has the same sections in the same order.

Ah, good to know. Fair enough, and it's easy enough to hide when I work on other types of projects.

I recently merged a significant refactor of the LSP Client internals, and one of the downstream goals of that is redoing the entire client connection workflow to be as hands-off as possible. The LSP status bar widget is probably going to go away as a result of this, along with the "couldn't connect" message.

Sounds great, thanks for the update!