Harden Azure Functions VS Code launch lifecycle and E2E coverage

[ellahathaway]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Post-merge review of #19001 identified seven directly related correctness and coverage gaps:

• Task capture can fail silently, breaking termination and cleanup
• The E2E test does not exercise shell quoting
• Natural host exit can signal a potentially recycled PID
• Invalid process IDs can become NaN and be reported as null
• dash and ash are incorrectly rejected as unsupported
• The Functions E2E implicitly relies on .NET 8 being installed
• Shell validation occurs only after building the project

These comments were submitted after #19001 had merged and therefore require a follow-up change.

Expected Behavior

• Existing or newly started func task executions are captured reliably.
• Run-mode termination is reported even when no task-start event is observed.
• Natural host exit does not attempt to terminate a stale worker PID.
• Invalid worker process IDs fail explicitly.
• POSIX-compatible dash and ash shells are supported.
• Shell and argument validation fails before building.
• The E2E test exercises real shell quoting.
• The E2E workflow explicitly installs every required .NET runtime.

Steps To Reproduce

See the linked review threads for individual scenarios and suggested regression coverage.

Exceptions (if any)

N/A

Aspire doctor output

N/A

Anything else?

Source PR: #19001

Completion should include focused unit coverage for lifecycle, PID validation, shell classification, and fail-fast behavior, plus an Azure Functions E2E fixture containing shell-sensitive arguments.

[joperezr]

🤖 Aspire triage pass — 2026-08-07 17:19 UTC

Area: area-vscode-extension, area-testing
Kind: bug
Repro: partial — individual scenarios described via the linked PR review threads on #19001; no standalone repro
Affected version(s): not specified in body (latest: 13.4.0; 13.5 wrapping up)
Severity: S3 — correctness and coverage gaps in the VS Code Azure Functions launch lifecycle; scoped to the extension with workarounds, not a core-runtime break

Urgency: ⚪ backlog — no milestone
Reason: post-merge hardening follow-up to #19001, not a regression and not S1/S2 (no milestone while 13.5 stabilizes)

Suggested owner(s): Adam Ratzman (@adamint) (score 9)
Evidence:

• adamint is the dominant recent author of merged area-vscode-extension PRs in the last 90d (e.g. Cache VS Code and ChromeDriver downloads for extension E2E tests #19012, Fix VS Code file AppHost build ownership #18984, Pin cacheable-request after npm supply-chain compromise #18997, Fix Windows global-tool Aspire CLI discovery #18940)
• CODEOWNERS lists Adam Ratzman (@adamint) and Ella Hathaway (@ellahathaway) for /extension (issue author Ella Hathaway (@ellahathaway) excluded as owner candidate)

Confidence: high
Needs human?: no

[adamint]

Repro of the seven #19001 follow-ups — six confirmed at the unit level, one config-only.

I ran the merged azureFunctions.ts (upstream/main @ 0863e6d) through its real createDebugSessionConfigurationCallback with a small scratch harness — same shape as extension/src/test/azureFunctionsDebugger.test.ts: stub vscode, DotNetService, and the AF startFuncProcess API, with process.kill swapped for a recorder so nothing is actually signalled. The real file is used verbatim; I only vary one condition at a time and read back what the callback does.

Environment: macOS 26.6 arm64, Node 24.3.0, .NET SDK 10.0.201, TypeScript 5.9.3 (tsc transpile → node).

Reproduced (real callback)

• Invalid PID → NaN → DCP pid:null (azureFunctions.ts:332). startFuncProcess returning { success: true, processId: 'worker-1' } yields session.processId = NaN — there's no Number.isInteger guard. That value flows to ProcessRestartedNotification.pid (AspireDebugSession.ts:585) and AspireDcpServer.sendNotificationCore does JSON.stringify({… pid }), which serialises NaN as "pid":null. Observed wire: {"notification_type":"processRestarted","session_id":"…","pid":null}.
• dash/ash rejected (:205). With an arg that forces shell resolution, automationProfile.osx = /bin/dash and /bin/ash both throw the unsupported-shell error, while /bin/bash, /bin/sh, /usr/bin/zsh classify and quote fine. The regex prefix alternation just doesn't include da|a.
• Validation after build (:315). Same /bin/dash case: the callback runs buildDotNetProject + getDotNetTargetPath and only then throws on the shell. Observed dotnet calls ["build:…","target:…"] before the throw — a static config error costs a full build first.
• E2E never exercises quoting (:115). The exact fixture args (--useHttps --cert <scratch>/https-e2e.pfx --password AspireE2E --port 7071) take the fast path: terminal.integrated config is read 0 times and args reach startFuncProcess verbatim. getFuncHostTaskShell/classifyFuncHostTaskShell/quoteFuncHostArgument are never called. Control: a --password "Aspire E2E p@ss'\" arg does resolve the shell and quote, so that surface is only covered by unit stubs today.
• Silent capture failure → stuck "Running" (:287). If startFuncProcess succeeds but no onDidStartTaskProcess fires (the executeIfNotActive already-active case), funcExecution stays undefined: a later task-end event early-returns on event.execution !== funcExecution, so in run mode termination never resolves (still pending after 200ms) and nothing is logged. Positive control (start event fires) resolves termination to the exit code, so it's the missing capture, not the harness.
• Natural exit signals a possibly-recycled PID (:342 → :67). On a natural task-end event, complete() → cleanupRun → killFuncProcess calls process.kill(workerPid) with no kill(pid, 0) liveness gate and without dropping the PID first. Recorder shows kill(999999) on the natural-exit path.

16/16 harness checks passed (including the positive controls).

Not run / config-only

• E2E implicitly needs .NET 8. I didn't run the Linux Functions shard here. But the generated project targets net8.0 (scripts/run-e2e.js) while the workflow's only Setup .NET uses global-json-file: global.json (SDK 10.0.201) with no dotnet-version: 8.0.x (extension-e2e-tests.yml:310) — so it leans on an 8.0 runtime/ref-packs baked into the runner image. Config-verified, not reproduced.

Limitations

The harness stubs vscode/DotNetService/the AF API, so this validates our lifecycle/PID/shell logic, not the real vscode-azurefunctions task boundary or a real shell — the E2E-coverage gaps (#2/#6) still want the actual extension E2E. This is reproduction only; no code changes. Scratch worktree/harness cleaned up.