workspace/symbol Fails to Recognize rootPath and Inconsistent Responses Without Debugging #949

Papadopulus · 2025-03-18T09:35:01Z

Papadopulus
Mar 18, 2025

Description
I'm encountering multiple issues with typescript-language-server when using its LSP capabilities, particularly with workspace/symbol and other features like hover, signature_help, implementation, and references. Despite correctly sending the rootUri during the initialize request, the server struggles to recognize the project root and provide complete responses unless specific conditions are met, which seem inefficient or inconsistent.

workspace/symbol Issue:
    When I call workspace/symbol with a query (e.g., "createApiResponse"), the server fails to find symbols unless I manually send textDocument/didOpen for every .ts file in the project. Even then, it returns only one symbol, despite there being many more in the project.
    I provide the rootUri in the initialize request (e.g., file:///path/to/my/project), and the project contains a valid tsconfig.json and multiple .ts files. However, the server behaves as if it doesn’t recognize the rootPath unless all files are explicitly opened.
   I tried to use workspaceFolders in the initialize request because rootUri is deprecated in favour of workspaceFolders, but i got the same result.

Inconsistent Responses Without Debugging:
    For features like hover, signature_help, implementation, and references, the server returns nothing or minimal information when running tests normally (without debugging). For example, a hover request might return an empty response or a brief description.
    If I run the test in debug mode and introduce a slight delay after calling my send_document_sync method (see code below) before making the request, the server returns a full, correct response (e.g., detailed hover information with types and documentation).
    -This suggests the server hasn’t finished processing documents when I make the request in non-debug mode, but it works fine with a manual delay in debug mode.

async def send_document_sync(
        self,
        document_uri: str,
        language_id: LanguageIdentifier,
    ) -> None:
        if not self._document_sync_clients:
            return

        if not document_uri.startswith("file://"):
            raise ValueError("Invalid or unsupported URI.")

        content = await asyncio.to_thread(Path(document_uri[7:]).read_text)

        doc = self._open_documents.get(document_uri)
        if not doc:
            doc = _OpenDocument(uri=document_uri, version=1, content=content)
            self._open_documents[document_uri] = doc
            text_document = TextDocumentItem(
                uri=doc.uri,
                languageId=language_id,
                version=doc.version,
                text=doc.content,
            )
            for lsp in self._document_sync_clients:
                await lsp.client.send_did_open(text_document)
            return

        if doc.content == content:
            return

        doc.version += 1
        doc.content = content

        changes = [TextDocumentContentChangeEvent(text=doc.content)]
        for lsp in self._document_sync_clients:
            await lsp.client.send_did_change(doc.uri, doc.version, changes)

Steps to Reproduce

Setup:

- A TypeScript project with tsconfig.json and multiple .ts files.
- rootUri set to the project directory (e.g., file:///home/user/project) in the initialize request.
- Using typescript-language-server --stdio as the server command.

Test Case:
- Initialize the client with rootUri and call workspace/symbol with a query present in multiple files.
Result: Returns one symbol or none unless didOpen is sent for every file.
- Open a single .ts file with didOpen, then request hover at a symbol without debugging.
Result: Empty or minimal response.
- In debug mode, add a delay (e.g., 1-2 seconds) after send_document_sync and before hover.
Result: Full hover information returned.

Expected Behavior

workspace/symbol should index the entire project based on the rootUri provided in initialize and return all matching symbols without requiring didOpen for every file.
Features like hover, signature_help, etc., should return complete responses consistently, regardless of debugging, once the document is synced.

Actual Behavior

workspace/symbol returns incomplete results (e.g., 1 symbol instead of many) unless all files are opened with didOpen.
Other features return nothing or partial responses without debugging and a manual delay after send_document_sync.

Environment

typescript-language-server version: 4.3.4
OS: Ubuntu 22.04
Project: TypeScript project with tsconfig.json and ~20 .ts files

Questions

How can the server reliably recognize the rootPath if it’s not working from the initialize request? Is there a specific configuration or step I’m missing?
Is there a way to get a notification from the server when it has finished processing documents, so I can call features like hover or workspace/symbol at the right time instead of guessing with delays?

Notes

Manually opening all files with didOpen is not a practical solution for larger projects. The inconsistent behavior between debug and non-debug modes suggests a timing or indexing issue on the server side. I’d appreciate any guidance or fixes to make this work reliably.

rchl · 2025-03-18T14:22:06Z

rchl
Mar 18, 2025
Maintainer

didOpen notification is required for many features to works - more info in Typescript lang server forces didOpenTextDocument call before answering LSP requests #636. But of course it's not necessary to open all files in the project when triggering workspace-related commands. The project must have finished loading though - see next point.
tsserver loads the project asynchronously and will only provide limited functionality until that happens. typescript-language-server reports this using the $/progress notification (the client must support progress notifiations). Here is a log from my LSP client showing this happening:

:: [15:18:49.682] <-- LSP-typescript window/workDoneProgress/create (0): {'token': '2b8063b6-f2bd-4d93-8262-c51c79bbce6e'}
:: [15:18:49.684] <-  LSP-typescript $/progress: {'token': '2b8063b6-f2bd-4d93-8262-c51c79bbce6e', 'value': {'kind': 'begin', 'title': 'Initializing JS/TS language features…'}}
:: [15:18:50.305] <-  LSP-typescript $/progress: {'token': '2b8063b6-f2bd-4d93-8262-c51c79bbce6e', 'value': {'kind': 'end'}}

Once the progress notification ends, it typically can be assumed that the project has loaded.

I don't know of any issues with respecting the rootPath.

2 replies

Papadopulus Mar 19, 2025
Author

Hi Rafał,

Thank you so much for your detailed and insightful response! It really helped me understand the behavior of typescript-language-server better and pointed me in the right direction. Following your advice, I was able to resolve part of my issue by waiting for the server to send the $/progress notification with value.kind: "end" before sending any requests (like hover, signature_help, etc.). This ensured that the server had finished its initial processing, and those features now work reliably in my tests without needing manual delays. I truly appreciate your guidance on this—it’s been a huge help!

However, I’m still facing an issue specifically with workspace/symbol. Even after waiting for the $/progress notification with kind: "end", the server throws the following error when I call workspace/symbol:

TypeScript Server Error (5.8.2)
No Project.
Error: No Project.
    at Object.ThrowNoProject (/home/node-js-testing-projects/express-typescript/node_modules/typescript/lib/typescript.js:185022:11)
   # ... [rest of the stack trace]

In my connect_and_initialize method, I’m sending the correct rootUri, and the initial initialize request and response complete successfully. The problem only occurs when I call workspace/symbol afterward. It feels like the server either isn’t indexing my tsconfig.json properly or I’m not waiting long enough for it to index all the files in the project. The catch is, unlike after send_did_open (where it signals completion via $/progress), the server doesn’t seem to provide feedback that it has finished indexing the entire project.

I tried a workaround by sending a textDocument/didOpen notification for one file before calling workspace/symbol, hoping it would trigger indexing. While this allowed the server to find the queried symbol (createApiResponse) in that specific file, it still only returned that one instance—ignoring other occurrences of the same symbol across the project. It’s as if the server isn’t indexing the full project, or I’m missing a step to make it do so.

Here’s my question for you: Is there a way to get explicit feedback from the server that it has successfully indexed the entire project? Or do you know of another solution to ensure workspace/symbol works across all files without needing to open every file manually? I’d love to hear your thoughts, as I’m a bit stuck on this last piece.

Thank you again for your time and expertise—it’s been incredibly valuable to me!

rchl Apr 1, 2025
Maintainer

The progress notification is for the project.

Not sure why Typescript thinks there is no project in your case. Hard to say without the logs.

Does Typescript (lsp server) have file access to your project? Obviously it needs that to be able to index it.
Is the file that you are opening with didOpen a part of the project (the one specified with rootUri)?
Is root URI correctly formatted and is there a valid tsconfig.json file within that path (although that last part shouldn't be necessary to be fair)?

If you can't figure it out and can't provide logs than another way to investigate could be to just use an editor of your choice with LSP logging enabled and inspect the requests that it's making. It should work there.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

workspace/symbol Fails to Recognize rootPath and Inconsistent Responses Without Debugging #949

{{title}}

Replies: 1 comment 2 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

workspace/symbol Fails to Recognize rootPath and Inconsistent Responses Without Debugging #949

Papadopulus Mar 18, 2025

Replies: 1 comment · 2 replies

rchl Mar 18, 2025 Maintainer

Papadopulus Mar 19, 2025 Author

rchl Apr 1, 2025 Maintainer

Papadopulus
Mar 18, 2025

Replies: 1 comment 2 replies

rchl
Mar 18, 2025
Maintainer

Papadopulus Mar 19, 2025
Author

rchl Apr 1, 2025
Maintainer