Repository navigation
Intermittent ~60s aspire start in WSL: warm TypeScript AppHost spends 44s in npm install #22194
Description
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
During a .NET Conf demo, aspire start in a prepared WSL 2 environment took about 60 seconds to report success. The preceding start of the same TypeScript AppHost took about 12 seconds.
The logs identify the main delay as the AppHost's root npm install, before the TypeScript AppHost is launched. That step took 44.077 seconds, even though npm reported the dependencies were already up to date. In the preceding run, the same step completed in approximately 1.1 seconds.
This is an observed intermittent startup stall, not a confirmed issue with detachment, Native AOT, or WSL itself.
The slow run was on 2026-11-10, 23:24:20.834–23:25:20.752 UTC (15:24 Pacific).
| Phase | Observed time |
|---|---|
| Initial setup, certificate check, managed server startup, and SDK generation | ~5.3 s |
AppHost npm install |
44.1 s |
| TypeScript type-check | ~3.5 s |
| Guest launch, Dashboard, and startup readiness | ~7.0 s |
Total until AppHost started successfully |
59.918 s |
Key lines from the slow child CLI log:
[2026-11-10 23:24:26.123] [DBUG] [GuestAppHostProject] Executing: /usr/local/bin/npm install
[2026-11-10 23:24:26.218] [INFO] [ProcessExecutionFactory] Process supervisor 5503: Started '/usr/local/bin/npm' (runtime PID 5510, owner PID 5458, cwd '/home/demo/demo2').
[2026-11-10 23:25:09.921] [INFO] [AppHost] up to date, audited 114 packages in 43s
[2026-11-10 23:25:10.200] [DBUG] [ProcessExecutionFactory] /usr/local/bin/npm(5503) exited with code: 0
Comparison from the preceding start:
[2026-11-10 22:17:11.245] [DBUG] [GuestAppHostProject] Executing: /usr/local/bin/npm install
[2026-11-10 22:17:12.195] [INFO] [AppHost] up to date, audited 114 packages in 759ms
Expected Behavior
A warm, unchanged application should not unexpectedly spend approximately 44 seconds in a no-op package install before its AppHost can launch. If the package manager must run, its phase/progress should make the source of a long wait clear.
Investigate whether the repeated install can be avoided when dependencies have not changed, and/or whether more precise package-manager timing would help diagnose stalls.
Steps To Reproduce
These are the setup and commands used for the observed incident; the intermittent delay has not been reproduced under controlled conditions.
-
Use a fresh Ubuntu 24.04 WSL 2 distro with native Linux Node.js/npm and the self-contained Aspire daily installed. No separately installed Linux .NET SDK, host, or shared runtime is present.
-
Scaffold the standard Express/React TypeScript starter:
aspire new aspire-ts-starter \ --name BundleDemo \ --output /home/demo/demo2 \ --channel daily \ --version 17.1.0-preview.1.26560.4 \ --non-interactive --nologo \ --suppress-agent-init --use-config-source false -
Use the template's HTTP launch profile for the local demo. The frontend and Express API code are unchanged.
-
Run and stop the app beforehand so the bundle, NuGet integrations, and npm dependencies are already acquired.
-
From
/home/demo/demo2, runaspire start. -
Observe an unusually long startup. In this incident it eventually succeeded after approximately one minute.
Exceptions (if any)
No fatal exception. The start and root npm install both exited successfully.
npm also printed audit findings and an install-script approval warning for esbuild. Those are retained in the logs, but there is no evidence that either warning explains the entire delay. No npm audit fix or script-approval changes were made during this investigation.
Aspire doctor output
Not captured at the time of the incident. The investigation preserved the historical logs without restarting the application or changing its configuration.
Anything else?
cc James Newton-King (@JamesNK)
Environment at the time:
- Aspire CLI:
17.1.0-preview.1.26560.4+a9a1f9bb3dc6c2af4895e0cffcfddf1210326be4(daily, build ID17.100.26.56004). - AppHost SDK / JavaScript hosting integration:
17.1.0-preview.1.26560.4. - WSL 2, Ubuntu 24.04.5; Linux
6.18.33.2-microsoft-standard-WSL2. - Node.js
v26.13.0, npm11.20.0. - App: the standard TypeScript AppHost with Express API and Vite/React frontend; no container resources.
What the logs establish:
- The parent spawned the detached child almost immediately; the dominant stall is inside that child's npm invocation.
- The bundle was already extracted and up to date.
- The NuGet integration package manifest was served from cache.
- The managed server began listening approximately 0.43 seconds after it was launched.
- npm's debug log shows successful audit and registry-metadata HTTP requests, without a recorded request timeout/retry. Their individual recorded durations do not account for the complete 44-second install.
- npm per-phase timing diagnostics were not enabled, so the exact internal cause of that install delay remains unknown. The audit activity alone is not proof that the audit caused the entire stall.
Full logs are included in expandable comments below: the slow parent/child CLI logs, the matching root npm install log, the preceding fast-run CLI logs, and the remaining correlated npm logs. Dashboard login tokens are redacted; paths use the demo account.
Activity
joperezr commentedon Nov 12, 2026
Full logs: slow start (2026-11-10 23:24 UTC)
Historical logs, with Dashboard login tokens redacted. Included as expandable text because the CLI attachment command does not support log/ZIP uploads.
cli_20261110T232420_914e50ab.log
cli_20261110T232421268_detach-child_497ac255bd0d453995f95cb21d4e4008.log
2026-11-10T23_24_26_515Z-debug-0.log
joperezr commentedon Nov 12, 2026
Full logs: preceding fast start (2026-11-10 22:17 UTC)
Historical logs, with Dashboard login tokens redacted. Included as expandable text because the CLI attachment command does not support log/ZIP uploads.
cli_20261110T221707_94f86277.log
cli_20261110T221708099_detach-child_5fd7f9a8a60c442d96f2ca8af67b51ab.log
joperezr commentedon Nov 12, 2026
Full logs: remaining npm processes from the slow start
Historical logs, with Dashboard login tokens redacted. Included as expandable text because the CLI attachment command does not support log/ZIP uploads.
2026-11-10T23_25_10_380Z-debug-0.log
2026-11-10T23_25_13_836Z-debug-0.log
2026-11-10T23_25_18_765Z-debug-0.log
2026-11-10T23_25_18_773Z-debug-0.log
2026-11-10T23_25_22_163Z-debug-0.log