Memory leak on Theia 1.68.2

[drochgenius]

Discussion

Problem

We have updated from Theia 1.65 to Theia 1.68.2 last week, following the Community Releases.
We observed that on Theia 1.68.2, the memory usage on our server saturates after a few hours after deployment, and renders the application unresponsive to users, users get quicked out and are unable to login, getting a 504. This forced us to rollback to 1.65.

If we revert to Theia 1.65, everything is stable again.

The only thing I could find that could be the cause of this issue is #16856
However, it's marked as fixed in version 1.68.2.

Did anyone else reported a similar issue with the 1.68 community release?
Do you have any pointer on what could be causing that?

The memory leak seems related to application usage.
The memory grows are users use the application, open tree views, web views, etc.
It grows quickly until, 1-2 hours after deployment, the server becomes unresponsible and service returns 504 Gateway Timeout errors.

Usage context

Let me share some context about how we use Theia.
We have built a CMS using Theia. The CMS is hosted internally and internal users and vendors use it to create and edit content for our various products. We have implemented a back-end contribution to enable users to authenticate to Theia via SAML from our internal Okta SSO portal. We have a bit under 100 active users.

These are the only Theia packages we are using:

        "@theia/core": "~1.65.0",
        "@theia/monaco": "~1.65.0",
        "@theia/plugin-ext": "~1.65.0",
        "@theia/plugin-ext-vscode": "~1.65.0"

Most of our contributions to Theia is in the form of a Visual Studio Code plugin.
The VSCode plugin essentially contributes tree view containers, tree views and web views.
The data in the webviews is populated from an external service, not from a file system.

As I said previously we have a Theia back-end contribution for Okta SSO integration, and we also have a front-end contribution to customize mennus and tree views.

We are deploying Theia using a custom Docker image based on Amazon Linux distribution with Node 22.

[github-actions[bot]]

Hi @drochgenius, thanks for starting this discussion! 👋

The Theia community will take a look soon. In the meantime, you might find helpful information in:

• 📖 Theia Documentation
• ❓ FAQ
• 💬 Previous Discussions

---

💙 Eclipse Theia is built and maintained by a community of contributors and sponsors. If Theia is valuable to your work, consider sponsoring the project. For professional support, training, or consulting services, learn more about available options.

[ndoschek]

Hi @drochgenius, thanks for the detailed report and for sharing your usage context.

I have not seem a similar report with v1.68, but your multi-user deployment with ~100 users is likely what makes this more visible.
We investigated the changes between v1.65.0 and v1.68.2 in the packages you are using. The backend messaging, connection handling, and plugin host lifecycle code is unchanged between these versions. However, several changes touch the exact areas you are using (tree views, webviews, widget lifecycle), most notably PR #16856 (widget disposal changes) and PR #16518 (new BadgeService for tree view/webview badges). The Lumino widget library was also upgraded from 2.5.0 to 2.7.2.

More importantly, PR #17021 (shipped in v1.69.0) fixed a long-standing memory leak where ContributionProvider retained references to child containers (see #10877). While this issue exists in both v1.65 and v1.68.2, the widget lifecycle changes in v1.68 may have made its impact more pronounced in multi-user deployments. The fix touched 51 files across the framework.

Would it be possible for you to try v1.69.0? That ContributionProvider fix is quite significant and is a likely candidate to resolve what you are seeing.
If that can resolve it, we can also look into patching the community release if needed.

TIA!

[drochgenius]

Thanks for getting back to me.
Sure, I will test this in the coming days and let you know whether 1.69.0 fixes the memory leak issue I am observing.