Memory leak / repeated schema-fetch loop when a TOML schema endpoint returns 403 or non-JSON

[iqdoctor]

We are seeing what looks like a memory leak or at least pathological memory retention in the VS Code extension Even Better TOML when a schema association exists but the schema endpoint does not return valid JSON.

In our case the file is ~/.codex/config.toml, which gets associated via SchemaStore with:

• https://developers.openai.com/codex/config-schema.json

From this host that URL responds with 403 and a non-schema body, and the TOML LSP repeatedly re-enters schema-dependent work on:

• hover
• completion
• documentSymbol

The important point is that this is reproducible without VS Code UI interaction by launching the bundled LSP server directly over Node IPC.

Environment

• Extension: tamasfe.even-better-toml 0.21.2
• Bundled server path:
  • /root/.vscode-server/extensions/tamasfe.even-better-toml-0.21.2/dist/server.js
• Host: Linux x86_64, remote VS Code Server session
• Node: v24.13.1 in the bundled repro run

Synthetic repro

I wrote a standalone harness that launches the bundled TOML server directly and simulates a client:

• script: /home/tools/server/codex/even-better-toml-detached-repro.js

It:

1. starts dist/server.js via fork(..., stdio: 'ipc')
2. sends a valid initialize
3. opens file:///root/.codex/config.toml
4. repeatedly calls:
   • textDocument/hover
   • textDocument/completion
   • textDocument/documentSymbol
5. samples RSS from /proc/<pid>/status

Repro results

Fresh detached baseline, 50 iterations:

{"workspace":"/home/tools/server","file":"/root/.codex/config.toml","detached":true,"iterations":50,"schemaEnabled":true,"catalogs":["https://www.schemastore.org/api/json/catalog.json"],"associationUri":null,"rssKbBefore":471616,"rssKbAfter":525888,"rssKbMax":525888,"detachedWarnings":151,"schemaFetchErrors":51,"completionErrors":50,"diagnosticsPublished":3}

Fresh non-detached baseline, same file but workspace /root:

{"workspace":"/root","file":"/root/.codex/config.toml","detached":false,"iterations":50,"schemaEnabled":true,"catalogs":["https://www.schemastore.org/api/json/catalog.json"],"associationUri":null,"rssKbBefore":384336,"rssKbAfter":473248,"rssKbMax":473248,"detachedWarnings":0,"schemaFetchErrors":51,"completionErrors":50,"diagnosticsPublished":3}

Longer detached soak, 150 iterations:

{"workspace":"/home/tools/server","file":"/root/.codex/config.toml","detached":true,"iterations":150,"schemaEnabled":true,"catalogs":["https://www.schemastore.org/api/json/catalog.json"],"associationUri":null,"rssKbBefore":819132,"rssKbAfter":537136,"rssKbMax":819132,"detachedWarnings":451,"schemaFetchErrors":151,"completionErrors":150,"diagnosticsPublished":3}

Relevant server log pattern on every iteration:

• using detached workspace for detached case
• failed to fetch schema
• completion: failed to collect schemas

The issue is not limited to detached files, because the same schema fetch/completion loop still reproduces when the file is no longer detached.

Control run

With schema support disabled:

{"workspace":"/home/tools/server","file":"/root/.codex/config.toml","detached":true,"iterations":50,"schemaEnabled":false,"catalogs":["https://www.schemastore.org/api/json/catalog.json"],"associationUri":null,"rssKbBefore":331908,"rssKbAfter":362372,"rssKbMax":362372,"detachedWarnings":151,"schemaFetchErrors":0,"completionErrors":0,"diagnosticsPublished":3}

So the problematic path is clearly in schema handling.

Expected behavior

If a schema endpoint returns 403 or non-JSON:

• the failure should be negatively cached
• repeated hover/completion/documentSymbol should not trigger repeated schema load work
• memory should remain bounded
• the server should degrade gracefully and keep editor features usable

Actual behavior

• schema fetch is retried repeatedly
• completion repeatedly re-enters schema collection and logs the same error
• RSS rises substantially and stays elevated

This looks like a client robustness issue even if the upstream schema endpoint is misconfigured.

Extra note

As a separate workaround attempt, I tried overriding the association to a local schema file instead of the remote URL. That removed the remote fetch failure but triggered a different failure mode, so this issue should be treated as the LSP's handling of repeated schema-load failures, not as a statement about the correctness of the schema itself.

If useful, I can provide the full synthetic harness and raw logs.

[DreamShark-Bytes]

Nice find. I was running into this issue myself. Thanks for both finding the issue and creating a fix for it.
Looks like it's not been applied yet.
For now I'm just going to move onto another TOML extension.