Visual Studio Code plugin sometimes fail to load on Theia 1.59

[drochgenius]

We are running Theia 1.59 as a hosted application with a custom VSCode plugin.
Up until version 1.58, everything was working fine, but now that we're updated to Theia 1.59, our users started to run in the following issue.

The VSCode plugin sometimes fails to load.
When this happens, there is nothing the user can do to restore the state of the application.

Here is the stack trace that shows in the browser:

ERROR [9f9de57b-5b47-45eb-82a7-184805d0c58d] Backend deployment failed.: 115.2 ms [Finished 3.651 s after frontend start]
log @ logger-protocol.ts:118
(anonymous) @ logger-frontend-module.ts:41
(anonymous) @ logger.ts:317
(anonymous) @ logger.ts:309
Promise.then
log @ logger.ts:304
log @ stopwatch.ts:176
error @ stopwatch.ts:131
syncPlugins @ hosted-plugin.ts:264
await in syncPlugins
doLoad @ hosted-plugin.ts:156
await in doLoad
(anonymous) @ hosted-plugin.ts:241
withProgress @ progress-service.ts:77
await in withProgress
runOperation @ hosted-plugin.ts:241
(anonymous) @ hosted-plugin.ts:14
Promise.then
AbstractHostedPluginSupport.load.debounce.leading @ hosted-plugin.ts:138
invokeFunc @ index.js:160
leadingEdge @ index.js:170
debounced @ index.js:235
onStart @ hosted-plugin.ts:129
onStart @ plugin-ext-frontend-module.ts:126
(anonymous) @ frontend-application.ts:295
startAsync @ stopwatch.ts:96
measure @ frontend-application.ts:322
startContributions @ frontend-application.ts:294
await in startContributions
(anonymous) @ frontend-application.ts:78
startAsync @ stopwatch.ts:96
measure @ frontend-application.ts:322
start @ frontend-application.ts:78
start @ index.js:130
(anonymous) @ index.js:120
await in (anonymous)
./src-gen/frontend/index.js @ index.js:132
__webpack_require__ @ bootstrap:19
(anonymous) @ startup:4
(anonymous) @ startup:4
Understand this errorAI
index.js:130 2025-03-31T17:38:26.034Z root ERROR Failed to load plugins: Error: spawn ENOMEM
    at ChildProcess.spawn (node:internal/child_process:420:11)
    at spawn (node:child_process:762:9)
    at Object.fork (node:child_process:172:10)
    at HostedPluginProcess.fork (/home/theia/node_modules/.pnpm/@theia+plugin-ext@1.59.0_@types+react@18.3.20_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@theia/plugin-ext/lib/hosted/node/hosted-plugin-process.js:150:33)
    at HostedPluginProcess.runPluginServer (/home/theia/node_modules/.pnpm/@theia+plugin-ext@1.59.0_@types+react@18.3.20_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@theia/plugin-ext/lib/hosted/node/hosted-plugin-process.js:110:34)
    at HostedPluginSupport.runPluginServer (/home/theia/node_modules/.pnpm/@theia+plugin-ext@1.59.0_@types+react@18.3.20_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@theia/plugin-ext/lib/hosted/node/hosted-plugin.js:65:38)
    at HostedPluginServerImpl.getDeployedPluginIds (/home/theia/node_modules/.pnpm/@theia+plugin-ext@1.59.0_@types+react@18.3.20_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@theia/plugin-ext/lib/hosted/node/plugin-service.js:78:31)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async RpcProxyFactory.onRequest (/home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/messaging/proxy-factory.js:134:24)
    at async RpcProtocol.handleRequest (/home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/message-rpc/rpc-protocol.js:184:28) 

Also, I have noticed that when the application is operating normally, there is this error that shows in the browser dev tools, and it keeps coming in every second or so. The id keeps incrementing.

ERROR Promise rejection not handled in one second: Error: no local service handler with id LoggerMain , 
reason: Error: no local service handler with id LoggerMain
logger-protocol.ts:118 2025-04-04T12:11:21.810Z plugin-host ERROR Error: No reply handler for reply with id: 6
    at RpcProtocol.handleReply (/home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/message-rpc/rpc-protocol.js:102:19)
    at RpcProtocol.handleMessage (/home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/message-rpc/rpc-protocol.js:83:26)
    at /home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/message-rpc/rpc-protocol.js:57:66
    at /home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/event.js:142:69
    at CallbackList.invoke (/home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/event.js:148:26)
    at Emitter.fire (/home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/event.js:263:36)
    at BatchingChannel.handleMessages (/home/theia/node_modules/.pnpm/@theia+plugin-ext@1.59.0_@types+react@18.3.20_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@theia/plugin-ext/lib/common/rpc-protocol.js:210:39)
    at /home/theia/node_modules/.pnpm/@theia+plugin-ext@1.59.0_@types+react@18.3.20_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@theia/plugin-ext/lib/common/rpc-protocol.js:165:49
    at /home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/event.js:142:69
    at CallbackList.invoke (/home/theia/node_modules/.pnpm/@theia+core@1.59.0/node_modules/@theia/core/lib/common/event.js:148:26)

Do you have any lead as to what could be happening here?

[drochgenius]

I have updated from Theia 1.58 to Theia 1.59 mainly to get the fix for the issue with refreshing tree views.
Re: #15312

There is another change that I've made at the same time I updated from Theia 1.58 to Theia 1.59.

I've moved my plugin from a user plugin to a deployed plugin.

I found that there are 3 ways to install VSCode plugins:

• user plugins (must be manually unzipped)
• local plugins
• deployed plugins

I have changed the way we install our plugin from user to deployed.
Is there any difference in the way plugins are installed that could cause such an issue?

In the meantime, I'll try to revert back to using user plugins.

[drochgenius]

I have rolled back to Theia 1.58 an hour ago, and the application now seems to be stable.

[drochgenius]

I confirm that on Theia 1.58.0, my users aren't experiencing out of memory issues installing my plugin.
However, on Theia 1.59.0, they are.
I am not changing anything other than updating Theia packages.

May be related or not, but our instance's back-end is only accessible through the company's VPN. So when users disconnect from the VPN and reconnect, they are experiencing this issue: #14516

Users are seeing a cascade of errors like this:
logger-protocol.ts:118 2025-04-04T12:11:21.810Z plugin-host ERROR Error: No reply handler for reply with id: 6
And the plugins cannot be activated, there is a message saying Activating plugin XXX for Theia in the status bar, that stays there forever until the user reloads the page.
I've applied the recommendation here to enable the reloadOnReconnect settings, and it mitigates this issue.
This last behaviour is observed on both 1.58 and 1.59 versions.

[drochgenius]

I have many users on the same Theia server, and from what I can see, it seems like socket connections remain open after the users get disconnected. This is eventually causing a memory leak.

This is only happening on Theia 1.59.
Setting reloadOnReconnect and "frontendConnectionTimeout": 3000 configuration options seem to address the problem.

In git, I see the the default value for frontendConnectionTimeout is 0, which seems appropriate as it should timeout the socket connection immediately when it is disconnected.

Also for reloadOnReconnect, it defaults to false, which I understand is what we want for the electron app.

[msujew]

cc @tsmaeder Any idea what could've changed in 1.59 that leads to this issue?

[drochgenius]

I confirm that since I have added the 2 following settings for the Theia browser app in the package.json, my users aren't facing the memory leak issue anymore with Theia 1.59:

Setting reloadOnReconnect: true and frontendConnectionTimeout: 3000 configuration options fixes the leak problem.
I cannot explain why, but have tested this with almost 100 users for a period of 2 weeks.

Here is an example for how to set these:
https://github.com/eclipse-theia/theia-ide/pull/441/files

[dmm9]

@msujew @tsmaeder
It is not just a small glitch. It causes data loss to users if they don't save before going away from keyboard.

I am also experiencing this issue since I upgraded from release 2025-02 to 2025-05. The worse part is that it spoils the electron app after computer goes to sleep/screensaver and wakes up again. The application goes nuts due to endless reconnection attempts. The only way to recover is restarting the electron app.

Without knowing much, it seems the frontend is trying to re-use rpc connection id's, but the backend generates new id's after client reconnects?

I am using browser for development and electron for distribution. Happy to provide logs and more details if that helps.

[dmm9]

@sdirix Yes, your config solves the issue for both browser and electron. The frontend is not reloaded after long sleep (it manages to reconnect in ~2.4s < 3000ms) and the backend doesn't complain anymore. Thanks!!

[tsmaeder]

@dmm9 be aware that if you set frontendConnectionTimeout = -1, in the browser case, your back ends will likely stay around forever. If I remember correctly, there are cases where the user closes the window which we simply cannot catch. And before you ask: "reloadOnReconnect" never worked reliably and t.b.h should be removed.

[tsmaeder]

I would suggest you implement your own lifecycle for your Java-based service so you can reconnect to it when the "same" front end reconnects.

[dmm9]

@tsmaeder thank you for the warnings, I'll keep them in mind (or, at least, documented here). The java backend is started after a user authentication, and it needs to be closed when the user closes the app. Otherwise a java instance remains dangling after each run. I didn't find any other means to clean up but to use onWillStop from the frontendApplicationContribution.

[sdirix]

In the Electron variant you have full information about how many windows are open. Whenever one is closed, you can then check whether you want to kill your corresponding Java backend.

For the Browser variant, the largest issue is already resolved: Identifying the user. So instead of cleaning up the Java backend directly on onWillStop, you can instead just start a custom timeout, e.g. 5 minutes or more for the Java backend associated with the user from the corresponding frontend. If the user reconnects again (same frontend or a new one), you can associate the Java backend with that new session. If they don't you can then kill the Java backend.