René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"@angular/build:unit-test hangs forever when two components in one file have identical inline styles","articleBody":"### Command\n\ntest\n\n### Is this a regression?\n\n- [x] Yes, this behavior used to work in the previous version\n\n### The previous version in which this bug was not present was\n\n21.2.9\n\n### Description\n\nWhen two component definitions in the same source file declare byte-identical inline `styles`, the `@angular/build:unit-test` builder (vitest browser runner, `watch:false`) runs all tests, prints the passing summary, and then never exits. In CI the job is killed at its timeout.\n\nThe hang is caused by a leaked esbuild build context. `process._getActiveHandles()` at the hang shows a single non-stdio handle: a `ChildProcess` for `…/@esbuild/…/esbuild --service=… --ping`. esbuild's service child is a singleton kept alive by any live build context, so one orphaned context keeps the Node event loop alive forever. Killing only that esbuild child makes the runner exit immediately with code 0.\n\n#### Root cause\n\nTwo compounding check-then-act races on the concurrent component-stylesheet bundling path:\n\n1. `Cache.getOrCreate` (`tools/esbuild/cache.ts`) is not concurrency-safe — it `await store.get()`, and only on `undefined` does it `await creator()` then `store.set()`. There is no in-flight promise memoization.\n\n2. Inline component styles are cached in a `MemoryCache` keyed on `[language, sha256(content), filename]` (`tools/esbuild/angular/component-stylesheets.ts` → `bundleInline`, `#inlineContexts`). Two components in the same file with identical CSS produce the same key.\n\n3. The compiler plugin bundles component stylesheets concurrently, so two `bundleInline` calls hit `getOrCreate` with that same key, both see an empty cache, and both run the creator — each constructing a `BundlerContext`.\n\n4. Even when they end up sharing one `BundlerContext`, the leak is sealed by a second race inside `BundlerContext.#performBundle()` (`tools/esbuild/bundler-context.ts`):\n\n   ```ts\n   if (this.#esbuildContext) {\n     result = await this.#esbuildContext.rebuild();\n   } else {\n     this.#esbuildContext = await context(this.#esbuildOptions); // await gap: both callers see undefined\n     result = await this.#esbuildContext.rebuild();\n   }\n   ```\n\n   Two concurrent `bundle()` calls both observe `#esbuildContext === undefined`, both call `context()`, and the second assignment overwrites the first. `dispose()` only disposes `#esbuildContext` (the second one); the first esbuild context is orphaned and never disposed, and `esbuild.stop()` is never called.\n\nInstrumenting a real run (hooking `BundlerContext.bundle`/`dispose`) shows 432 contexts created, 431 disposed — exactly one orphan, whose `bundleInline` arguments are a pair of components with identical inline CSS. Differentiating the CSS by one byte balances the counts and the process exits cleanly.\n\nSequential bundling does not leak (the second call reuses `#esbuildContext` via `rebuild()`); the leak strictly requires the concurrency that parallel stylesheet transforms reliably hit, so it is deterministic.\n\n### Minimal Reproduction\n\nRepo: \u003clink to a pushed copy of cc-12526-bug\u003e (a stock `@angular/build:unit-test` setup plus two specs). A zip is attached below.\n\n```bash\nnpm install\nnpx playwright install chromium\n\nnpm run test:hang   # two components, IDENTICAL inline styles -\u003e tests pass, then HANGS FOREVER\nnpm run test:ok     # same, one byte different               -\u003e tests pass, EXITS code 0\n```\n\nThe two scenarios live in separate source folders (`src/hang/`, `src/ok/`) with their own `tsConfig`/build configuration, because the unit-test builder bundles every spec matched by the build's tsConfig (not just those selected by the test `include`); a single shared build would let the duplicate-style spec poison the \"ok\" run too.\n\nThe only difference between hanging and passing is whether two inline `styles` strings are byte-identical:\n\n```ts\n// hang: ComponentA and ComponentB both use\nstyles: [`.box { width: 100px; height: 100px; }`]\n\n// ok: ComponentB differs by one byte\nstyles: [`.box { width: 100px; height: 100px; /* one byte different */ }`]\n```\n\nExpected: both commands exit with code 0 after the tests pass.\nActual: `test:hang` never exits; `test:ok` exits cleanly.\n\n### Exception or Error\n\n```text\n(no error — tests pass, vitest prints its summary, then the process hangs)\n\n Test Files  1 passed (1)\n      Tests  1 passed (1)\n\n# process._getActiveHandles() shows one lingering handle:\nChildProcess  .../@esbuild/\u003cplatform\u003e/esbuild(.exe) --service=\u003cver\u003e --ping\n```\n\n### Your Environment\n\n```text\n@angular/build: 22.0.0   (also reproduced on current main)\n@angular/cli:   22.0.0\nvitest:         4.1.0\n@vitest/browser-playwright: 4.1.0\nplaywright:     1.58.2\nNode.js:        22.22.3\nOS:             Windows 11 (also reproduces on Linux CI)\nRunner:         @angular/build:unit-test, vitest browser (Chromium), watch:false\n```\n\n### Anything else relevant?\n\n- Not a duplicate of #33201 (esbuild child after `ng build`): that path (`build-action`/`watch:false`) is fixed in 22.0.0 and disposes its context correctly; this leak is one level down in the stylesheet bundler's per-context creation.\n- Not a duplicate of #32832 (vitest `close()` vs `exit()`, fork-pool worker IPC handles): in browser mode there are no fork workers, and the only lingering handle here is the esbuild child, not a worker socket. `ctx.exit()`'s force-exit safety net would mask this hang, but the orphaned context would remain.\n- Suggested fix: memoize the in-flight `context()` promise in `BundlerContext.#performBundle()` (clearing it in `dispose()`) so concurrent `bundle()` calls share one esbuild context — the same \"create-once guard\" shape as f102f815e (Initiate PostCSS only once). Making `Cache.getOrCreate` store the pending creator promise would additionally harden the ~16 other call sites, but is not sufficient on its own for this bug.\n- A \"fix-it-in-userland\" workaround is to ensure no two components in one file share byte-identical inline `styles` (change a selector, value, or add a comment).\n\n[cc-12526-bug.zip](https://github.com/user-attachments/files/28647484/cc-12526-bug.zip)","author":{"url":"https://github.com/Klaster1","@type":"Person","name":"Klaster1"},"datePublished":"2026-06-05T16:52:05.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/33317/angular-cli/issues/33317"}