`workspace/symbols` sometimes returns empty results

[Eskibear]

Describe the bug

workspace/symbols sometimes returns empty results. Leading to empty list in beans/mappings view.

When project is added/removed or classpaths changes, we re-fetch static beans/mappings from workspace symbols as below.

const beans = await stsApi.client.sendRequest("workspace/symbol", {"query": "@+"}) as any[];
const mappings = await stsApi.client.sendRequest("workspace/symbol", {"query": "@/"}) as any[];
console.log({beans, mappings});

To Reproduce

As described, sometimes occur. So I try and print the responses as below, catching one scene.

Sample

with vscode spring tools v1.38.0

[BoykoAlex]

@Eskibear Id this the latest released version of Boot language server or the latest from the main branch?

[Eskibear]

released version from marketplace.

[martinlippert]

I am trying remote dev containers again, incl. Codespaces, and I observe that the Send Classpath Notifications message sometimes doesn't appear. It looks to me like the classpath notification mechanism is not 100% reliable and needs to be analyzed in more depth here.

It also seems to be a bit overly complicated, so it feels extremely hard to debug and investigate this.

[martinlippert]

I have seen this problem myself as well while testing a lot of things in VSCode, Remote Containers, and Codespaces. Need to investigate whether this happens in combination with the missing classpath information message or if this is an independent problem. I vaguely remember that I saw at least once the empty beans view, but symbols showed when executing the "search for symbols in workspace" command (which would mean the issue is not related to the classpath message problem mentioned), but I need to verify this as a next step.

[Eskibear]

I vaguely remember that I saw at least once the empty beans view

There's a known regression issue in dashboard extension v0.7.0 introduced when we were improving the performance. List of static beans and mappings can be empty if Spring LS starts slowly and doesn't respond within a period of time. That was fixed in v0.7.1 (will be released in this week). Currently you can use latest pre-release bits to get rid of its influence, where we send another request to get symbols before rendering the list, ensuring the data is updated.

[martinlippert]

@Eskibear Thanks for the update, good to know. But you still observe the issue that you sometimes you get an empty response for beans and mappings, right?

Additional question: When do you observe the slowness where the spring tools do not respond in a specific period of time? And how long is this period exactly?

[Eskibear]

But you still observe the issue that you sometimes you get an empty response for beans and mappings, right?

Yes, there's some race condition in current impl of dashboard extension. Without a specific API, it has to proactively poll workspace/symbols to get static beans/mappings, without knowing whether an empty response is because a) Spring LS not yet ready or b) the project itself indeed has no symbols. Whenever classpath changes, it polls for latest static info. And I set a 'magic' timeout (5s) to prevent infinite polling in case of unexpected error.

When do you observe the slowness where the spring tools do not respond in a specific period of time? And how long is this period exactly?

At the very beginning when a project is opened. At first Spring LS will always respond the request with empty results. The time depends on project scale and machine power. Timeout for polling static information is currently set to 5s.

[martinlippert]

@Eskibear When a project changes, we wipe all symbols from the internal symbols cache and compute the news ones. This takes a while, depending on the size of the project and its classpath. We can try to improve performance in this space, but the fundamental race condition will remain: the dashboard doesn't really know when the spring-boot-ls is done and all the new symbols are ready to be visualized.

The polling mechanism or a timeout sounds like reasonable workarounds, but the fundamental problem remains. This sounds to me like a notification mechanism is needed here to allow the spring-boot-ls to signal when bulk changes to symbols are ready to be consumed by someone else.

Instead, we could also change the way the spring-boot-ls deals with symbol requests and let those requests return results only when there are all symbol change activities are done, but that can easily cause the "go to symbols in workspace" dialog to not show anything for a longer while, which I don't really like.

WDYT?

[martinlippert]

@Eskibear We might be able to avoid the emptiness of the symbols when you ask for them by returning old cached symbols until the new ones are ready, but that doesn't really solve the problem. It would mean that you would always get the "correct" set of symbols (empty means no symbols), but you never really know whether a short moment later another set of symbols would be available.

[Eskibear]

From the perspective of a downstream extension, I would expect the result exactly matching with the status of my workspace when workspace/symbol request is sent. Same for the coming API (if we will have on in the future). Returning the results only after all the actities are done is the most straightforward approach to me, but seems that you have more concerns.

but that can easily cause the "go to symbols in workspace" dialog to not show anything for a longer while, which I don't really like.

I have a little bit different taste here. As vscode will pop up the dialog immediately with a progress bar indicating the data is still on the way, I myself don't think it's a big problem unless it's taking way too long like tens of seconds (but that can be another thing to optimize, like prefetching symbols in background whenever document changes, with a reasonable debounce time of course).

Here the biggest confusion of empty result is, I cannot distinguish whether it's because it hasn't finished the calculation or the result is indeed emtpy (aka, no symbols in this workspace). Currently we have the assumption that it's impossible to have no symbols in a spring boot project, so we keep polling until it's not empty.

Anyway it's not a must to change the behavior, all I wanted is to avoid the case that developers see no/incomplete beans/mappings when they open a project which should have static info.

• notification mechanism + workspace/symbol returns the cache. It's fine. And we don't keep sending many requesting while polling for the results.
• polling mechanism. As long as there is a signal/sign indicating we get the correct result and the polling should be ended.