Prevent conda activation hangs

[bschnurr]

Summary

• avoid joining conda activation through the VS UI thread while constructing launch environments
• add a 30-second timeout for conda activation and kill timed-out activation processes
• avoid holding the activation cache lock while waiting on external activation processes
• do not cache timeout results, so transient activation hangs do not poison the cache
• make the conda activation cache key hash code match its case-insensitive equality semantics
• add regression tests for activation timeout behavior and timeout cache behavior

Root cause

Conda activation was invoked from GetFullEnvironment through UIThread.InvokeTaskSync with CancellationToken.None. The delegated work launched activate.bat and python.exe to capture the activated environment, then awaited process completion with no timeout while holding the activation cache lock. If activation or the child Python process never exited, devenv.exe could remain stuck in the UI-thread join path indefinitely, and other activation requests could block behind the cache lock.

Behavior after this change

Activation is still exposed through the existing synchronous environment-construction path, but the external activation wait is moved out of the VS UI-thread invocation path and is bounded by a timeout. On timeout, PTVS logs a Trace warning, kills the activation process, returns an empty activation environment for that attempt, and leaves the cache unmodified so a later activation can retry.

Tradeoffs / follow-ups

• If GetFullEnvironment is called on the UI thread, the UI may still be blocked until activation completes or the 30-second timeout expires; this is not a full async UI/progress refactor.
• Very slow conda installations may time out and launch without activation-provided environment variables.
• Concurrent cold-cache requests for the same environment may now run duplicate activation attempts because the global cache lock is no longer held during process execution.
• proc.Kill() terminates the started activation process; if child processes survive in some scenarios, process-tree termination may be needed later.
• Timeout diagnostics currently use Trace.TraceWarning only; Activity Log or telemetry may be useful follow-ups.

Validation

• msbuild Python\dirs.proj /p:VSTarget=18.0 /p:DeployExtension=true /p:RegisterOutputPackage=true
• vstest.console.exe BuildOutput\Debug18.0\raw\binaries\PythonToolsTests.dll /Tests:PythonToolsTests.CondaInterpreterFactoryTests.CondaActivationTimesOut,PythonToolsTests.CondaInterpreterFactoryTests.CondaActivationTimeoutIsNotCached /Logger:Console;Verbosity=minimal

[Copilot]

Pull request overview

This PR addresses potential Visual Studio hangs during conda environment activation by bounding activation time, reducing lock contention in the activation cache, and ensuring cache key hashing matches case-insensitive equality semantics. It also adds regression tests to validate timeout behavior and that timeouts do not poison the cache.

Changes:

• Add a 30-second conda activation timeout, kill timed-out activation processes, and avoid caching timeout results.
• Reduce activation cache lock duration by moving external process waiting outside the cache lock.
• Add tests covering activation timeout behavior, timeout logging, and non-caching of timeouts.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
Python/Tests/Core/CondaInterpreterFactoryTests.cs	Adds regression tests for conda activation timeout, logging, and non-caching behavior.
Python/Product/VSInterpreters/PackageManager/CondaUtils.cs	Implements timeout + process kill, refactors cache locking, and fixes cache key hash semantics.
Python/Product/VSInterpreters/Interpreter/LaunchConfigurationUtils.cs	Removes UI-thread join path for conda activation by moving work onto a background task and adds logger plumb-through.
Python/Product/PythonTools/PythonToolsService.cs	Passes the service logger into environment construction to enable timeout event logging.

[bschnurr]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[rchiodo]

GitHub cannot anchor PR review comments to unchanged lines in the diff. Falling back to a general PR comment for Python/Product/VSInterpreters/PackageManager/CondaUtils.cs:L1.

📍 GetActivationEnvironmentVariablesForPrefixUncachedAsync
The success path switched from await proc to await Task.Run(() => proc.Wait(timeout)). WaitForExit(Int32) returning true does not guarantee async OutputDataReceived handlers have flushed; the not-yet-dispatched JSON env line can be discarded, so ParseEnvironmentVariables returns empty and that empty result gets cached (ShouldCache=true) for the process lifetime — a silent, sticky loss of activation env vars. Fix: after a successful (exited==true) wait, call the parameterless proc.Wait() to drain async stdout before reading StandardOutputLines/ExitCode.

[rchiodo]

GitHub cannot anchor PR review comments to unchanged lines in the diff. Falling back to a general PR comment for Python/Product/VSInterpreters/PackageManager/CondaUtils.cs:L1.

📍 proc.Kill on timeout
proc.Kill() terminates only the activate.bat/cmd process, not the & python.exe child it spawns, so a timeout can leak an orphaned python.exe. Acceptable to defer per the PR's stated follow-up, but process-tree termination should be tracked so the timeout path doesn't accumulate orphaned children.

[rchiodo]

Main concern: after a successful timed wait, drain async stdout (parameterless proc.Wait()) before reading StandardOutputLines/ExitCode, otherwise a successful activation can intermittently parse empty and cache that empty result. The timeout/cache structure otherwise looks sound.

[bschnurr]

@rchiodo addressed the stdout drain concern in 1d5c13b by draining after a successful timed wait before reading output/ExitCode. Also strengthened CondaActivationTimeoutIsNotCached with a large env payload. Process-tree cleanup is tracked separately in #8560.

[rchiodo]

Approved via Review Center.

[rchiodo]

Looks good — the hang fix (move conda activation off the UI-thread join path, bound it with a 30s timeout, kill timed-out processes, and skip caching timeout results) is sound and well-tested. The remaining first-pass notes were all non-blocking nits, out-of-scope follow-ups, or premised on a ProcessOutput.cs change that isn't in this PR, so none were posted.

[rchiodo]

Approved via Review Center.

[bschnurr]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[rchiodo]

Looks good — the timeout + don't-cache-on-timeout approach is a solid, targeted fix and the regression tests cover the key behaviors. Approving.

[rchiodo]

Approved via Review Center.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud