Is this a bug report or a feature request?

• Bug Report
• Feature Request

Summary

Angular Language Service 22.2.0 entered a self-sustaining project-reload/diagnostics loop in a multi-root Nx workspace. A TypeScript file had been deleted on disk while its editor remained open, and an external Angular component template from a different worktree was also open. The server repeatedly failed to find the deleted file's configured project, reloaded/re-analyzed the template's library project roughly every 1–2 seconds, and eventually aborted with a JavaScript heap OOM near 4 GB.

Closing the two editors associated with the deleted path (ordinary editor and Git diff), then running Angular: Restart Angular Language server, stopped the loop without reloading VS Code. The external template remained open and its language features worked afterwards.

Please provide the steps to reproduce the issue [Bug Report only]

Observed sequence in the affected workspace; not yet independently reproduced in a standalone minimal project:

1. Open an Nx monorepo in VS Code with multiple linked worktree folders in one multi-root window.
2. Keep an external .component.html template open in a library whose tsconfig.json is solution-style (files: [] with references to the library/spec configs). Its sibling component TypeScript editor is not open.
3. Have a TypeScript editor open in another worktree, then delete that TypeScript file on disk while leaving its editor open. In the observed incident, both its ordinary editor and Git diff remained open.
4. The server repeatedly logs No config file for the deleted path, interleaved with repeated enabling of the template library project.
5. Within approximately 43–60 seconds per process lifetime, the heap reaches approximately 4 GB and the server aborts. Automatic restarts repeat the same sequence until the language client gives up after five crashes in three minutes.

There is no public minimal reproduction yet; the original workspace is private. The path names and layout below are anonymized. These steps describe the observed state and sequence, not a confirmed universal reproducer.

Please provide the expected behavior vs the actual behavior you encountered [Bug Report only]

Expected: An editor whose file was removed from disk should not cause repeated teardown/recreation and full Angular analysis of another open template's configured project. The server should settle and continue providing template features.

Actual: The same project-loading messages repeat about once per second, including repeated No config file errors for the deleted TS path. The server exhausts its heap, restarts, and eventually stops restarting. Template diagnostics/navigation become unavailable.

Recovery observed: Close only the saved editors for the deleted path, then restart the Angular language server. With the same workspace folders and external template still open, the log settled after about eight seconds. The replacement process remained alive for more than four minutes at approximately 1.4 GB RSS, with no further missing-file messages or crash. Template-to-component navigation was manually verified. This is current-session recovery, not evidence of permanent prevention.

Please provide the exception or error you saw [Bug Report only]

Representative excerpt, with paths anonymized:

[Info  - 19:44:51] Disabling language service for /workspace/worktree-a/tsconfig.json because project is not an Angular project ('@angular/core' could not be found).
[Error - 19:44:51] No config file for /workspace/worktree-a/libs/backend/src/deleted-file.ts
[Info  - 19:44:51] Disabling language service for /workspace/worktree-b/tsconfig.json because project is not an Angular project ('@angular/core' could not be found).
[Info  - 19:44:51] Enabling language service for /workspace/worktree-b/libs/frontend/shared/tsconfig.lib.json.
[Info  - 19:44:52] Disabling language service for /workspace/worktree-a/tsconfig.json because project is not an Angular project ('@angular/core' could not be found).
[Error - 19:44:52] No config file for /workspace/worktree-a/libs/backend/src/deleted-file.ts
[Info  - 19:44:53] Disabling language service for /workspace/worktree-b/tsconfig.json because project is not an Angular project ('@angular/core' could not be found).
[Info  - 19:44:53] Enabling language service for /workspace/worktree-b/libs/frontend/shared/tsconfig.lib.json.

[3348:0x12800810000] 43091 ms: Scavenge 4014.9 (4071.5) -> 4002.6 (4083.2) MB, pooled: 0.0 MB, 4.70 / 0.00 ms (average mu = 0.527, current mu = 0.565) allocation failure;
[3348:0x12800810000] 43122 ms: Scavenge 4026.8 (4083.2) -> 4011.4 (4090.7) MB, pooled: 0.0 MB, 4.83 / 0.00 ms (average mu = 0.527, current mu = 0.565) allocation failure;

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
[Error - 19:45:28] Server process exited with signal SIGABRT.
[Error - 19:45:28] The Angular Language Service server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.

Environment

• VS Code: 1.145.0
• OS: macOS 26.6.2, arm64
• Extension: angular.ng-template 22.2.0
• Loaded @angular/language-service: 22.2.0
• Loaded typescript/lib/tsserverlibrary: 6.0.3
• Angular in the affected worktrees: 22.2.4. Other folders in the multi-root window use 21.2.10 and 22.1.8.
• Multi-root window: 35 linked worktree folders
• Server runtime: VS Code's Code Helper (Plugin) process
• angular.server.useClientSideFileWatcher: enabled (visible in the server arguments)

The same window/folder set was stable for approximately 20 minutes before the deleted-file error/reload loop began. Workspace size may amplify the cost, but does not by itself explain the transition into the continuous loop.

Suspected mechanism (code-traced; not an isolated reproduction)

There appears to be an interaction between external-template project recovery and TypeScript project cleanup:

1. Project loading calls enableLanguageServiceForProject, which performs Angular analysis and refreshDiagnostics().
2. A projects-updated event schedules diagnostics for open files.
3. For the deleted TypeScript file, getDefaultProjectForScriptInfo calls openClientFile, cannot find a configured project, and reports No config file.
4. TypeScript's open-client-file path also runs orphan project cleanup. A solution-style template's association established by attachToComponentProject may not be preserved by that cleanup.
5. Processing the still-open external template then calls loadProjectForExternalTemplate / attachToComponentProject, loading and analyzing the library project again and scheduling more diagnostics.

This is consistent with the repeated log sequence and the observed recovery, but the exact heap-retention cause and causality of every internal step have not been independently established.

The recovery methods are present in 14fbe04612, which fixed #69768. This may be a relevant interaction/regression to investigate, not a claim that the commit alone is proven to cause the OOM.

An earlier log episode also showed repeated external-template project reloads and OOMs without a deleted-file error, so a deleted TS file may be one trigger rather than a necessary condition.

Related reports checked: #65356 and #65484 describe older language-service OOM incidents, but do not identify this particular solution-style template/project-reload sequence.