python bug: "Could not start runtime: failed to resolve interpreter"

[austin3dickey]

System details:

Positron and OS details:

Positron Dev Version: 2025.05.0 build 0
Code - OSS Version: 1.98.0
Commit: Unknown
Date: Unknown
Electron: 34.2.0
Chromium: 132.0.6834.196
Node.js: 20.18.2
V8: 13.2.152.36-electron.0
OS: Darwin arm64 24.3.0

Current commit: 11b1f19

Interpreter details:

Python 3.12.8 managed by uv

Describe the issue:

Sometimes when I open a workspace quickly, the recommended interpreter tries to start up and fails with error Could not start runtime: failed to resolve interpreter. If I try again, it succeeds.

Steps to reproduce the issue:

1. Create a new uv project and its venv. For me, this uses Python 3.12.8.

uv init proj
cd proj
uv venv

2. Open a fresh Positron with no state. No workspace should be selected. It should start "Discovering interpreters".
3. Quickly Open Folder to the proj workspace before it finishes discovering.

Expected or desired behavior:

A new session should start using the proj/.venv/bin/python interpreter

Were there any error messages in the UI, Output panel, or Developer Tools console?

Some possibly relevant logs from the developer tools console:

09:08:08.988 INFO Language runtime e2658114dd62ac56fef123f526dc50e1 (language: Python name: Python 3.12.8 (Venv: .venv) version: 3.12.8) automatically starting. Source: The ms-python.python extension requested the runtime to be started immediately.
09:08:08.988 DEBUG [Ext host 0] Runtime manager for 'Python 3.12.8 (Venv: .venv)': true
09:08:09.029 ERR Starting language runtime failed. Reason: Could not start runtime: failed to resolve interpreter /Users/austin/proj/.venv/bin/python
09:08:09.029 DEBUG Error starting runtime session: Could not start runtime: failed to resolve interpreter /Users/austin/proj/.venv/bin/python
09:08:09.035 ERR Could not start runtime: failed to resolve interpreter /Users/austin/proj/.venv/bin/python
09:08:09.224 DEBUG [Runtime startup] Discovery completed for extension host with id: 0.
09:08:09.227 ERR An unknown error occurred. Please consult the log for more details.

The Console shows

Python 3.12.8 (Venv: .venv) starting.
Error
Could not start runtime: failed to resolve interpreter /Users/austin/proj/.venv/bin/python

Some relevant logs from Python Locator:

2025-04-10 09:08:04.986 [debug] Reporting Environment PythonEnvironment { display_name: None, name: None, executable: Some("/Users/austin/proj/.venv/bin/python"), kind: Some(Venv), version: Some("3.12.8"), prefix: Some("/Users/austin/proj/.venv"), manager: None, project: None, arch: None, symlinks: Some(["/Users/austin/proj/.venv/bin/python", "/Users/austin/proj/.venv/bin/python3", "/Users/austin/proj/.venv/bin/python3.12"]) }
2025-04-10 09:08:04.986 [info] Discovered env: /Users/austin/proj/.venv/bin/python
2025-04-10 09:08:45.401 [debug] Resolving env "/Users/austin/proj/.venv/bin/python"

And from Python Language Pack:

2025-04-10 09:08:05.005 [info] pythonRuntimeDiscoverer: recommended interpreter: /Users/austin/proj/.venv/bin/python
2025-04-10 09:08:05.527 [debug] Found interpreter for /Users/austin/proj/.venv/bin/python,/Users/austin/repos/positron/extensions/positron-python/python_files/interpreterInfo.py
2025-04-10 09:08:05.529 [info] pythonRuntimeDiscoverer: registering runtime for interpreter /Users/austin/proj/.venv/bin/python with id e2658114dd62ac56fef123f526dc50e1
2025-04-10 09:08:08.989 [info] createPythonSession: kernelSpec argv: /Users/austin/proj/.venv/bin/python,/Users/austin/repos/positron/extensions/positron-python/python_files/posit/positron_language_server.py,-f,{connection_file},--logfile,{log_file},--loglevel=error,--session-mode=console
2025-04-10 09:08:45.426 [info] Found uv environment: /Users/austin/proj/.venv/bin/python
2025-04-10 09:08:45.426 [debug] Python API env change detected /Users/austin/proj/.venv/bin/python update
2025-04-10 09:08:45.426 [info] Python interpreter path: ~/proj/.venv/bin/python

I am also pretty sure I saw a telemetry event at some point in the past with this error from PET: https://github.com/microsoft/python-environment-tools/blob/845945b830297a50de0e24020b980a65e4820559/crates/pet/src/jsonrpc.rs#L354

[austin3dickey]

My running hypothesis is we're trying to start the session before the interpreter is resolved, and that's causing problems.

This is the error that's thrown:

positron/extensions/positron-python/src/client/positron/session.ts

Line 416 in 11b1f19

throw new Error(`Could not start runtime: failed to resolve interpreter ${this._pythonPath}`);

That getInterpreterDetails() method calls resolveEnv() which tells PET to resolve the environment, and at some point it's not able to resolve. But it feels like a race condition because it's able to resolve later. And if I don't move as quickly, everything works fine.

[austin3dickey]

yeah here's the aforementioned PET error in the python language pack:

2025-04-10 11:01:50.600 [error] Python Extension: sendTelemetry [ResponseError: Failed to resolve env "~/proj/.venv/bin/python"
	at handleResponse (/Users/austin/repos/positron/extensions/positron-python/node_modules/vscode-jsonrpc/lib/common/connection.js:606:48)
	at handleMessage (/Users/austin/repos/positron/extensions/positron-python/node_modules/vscode-jsonrpc/lib/common/connection.js:443:20)
	at Immediate.<anonymous> (/Users/austin/repos/positron/extensions/positron-python/node_modules/vscode-jsonrpc/lib/common/connection.js:413:30)
	at process.processImmediate (node:internal/timers:483:21)
	at process.callbackTrampoline (node:internal/async_hooks:130:17)] {
  code: -4,
  data: undefined
}

[austin3dickey]

I switched off PET and can't trigger this error, so we can look around the PET code.

[austin3dickey]

Okay, I think I've narrowed it down a bit. When we resolve the env here:

positron/extensions/positron-python/src/client/pythonEnvironments/nativeAPI.ts

Line 556 in c264519

const native = await this.finder.resolve(envPath);

There is a chance, depending on a race condition, that this.finder is not the "normal" NativePythonFinder, but instead this "untrusted" NativePythonFinder:

positron/extensions/positron-python/src/client/pythonEnvironments/base/locators/common/nativePythonFinder.ts

Lines 506 to 524 in c264519

	if (!isTrusted()) {
	return {
	async *refresh() {
	traceError('Python discovery not supported in untrusted workspace');
	yield* [];
	},
	async resolve() {
	traceError('Python discovery not supported in untrusted workspace');
	return {};
	},
	async getCondaInfo() {
	traceError('Python discovery not supported in untrusted workspace');
	return ({} as unknown) as NativeCondaInfo;
	},
	dispose() {
	// do nothing
	},
	};
	}

That seems to be triggered since I'm opening up a project in an "untrusted" folder originally. I'm not sure what work gets done before vs after I click "trust", but that's the race.

[austin3dickey]

I can confirm that once I "trust" a parent folder, this problem never seems to happen for any workspaces in that folder. So this problem is probably extremely uncommon, only happening in a very specific scenario for the first time you open a workspace. We'll have to decide whether it's worth putting effort into resolving the race condition, because it seems like it could require some significant messing around in upstream code.

---

As a side note, the PET error above with code -4 seems to be a red herring. While testing in a trusted folder, I was able to open a workspace and successfully resolve and start its venv session at /Users/austin/proj/.venv/bin/python. But the Python Language Pack logs still show that error, saying it wasn't able to resolve ~/proj/.venv/bin/python. In the Python Locator logs, it says

2025-04-14 09:19:53.762 [debug] Resolving env "~/proj/.venv/bin/python"
2025-04-14 09:19:53.763 [debug] Executing Python: ~/proj/.venv/bin/python -c import json, sys; print('093385e9-59f7-4a16-a604-14bf206256fe');print(json.dumps({'version': '.'.join(str(n) for n in sys.version_info), 'sys_prefix': sys.prefix, 'executable': sys.executable, 'is64_bit': sys.maxsize > 2**32}))
2025-04-14 09:19:53.763 [error] Failed to execute Python to resolve info "~/proj/.venv/bin/python": No such file or directory (os error 2)
2025-04-14 09:19:53.763 [warning] Unknown Python Env "~/proj/.venv/bin/python"
2025-04-14 09:19:53.763 [error] Failed to resolve env "~/proj/.venv/bin/python"

So this probably just has to do with path expansion and doesn't affect the eventual resolution of the interpreter. We can ignore this red herring.

[austin3dickey]

I owe a rambling update because I'll be working on a different project for a couple days. Did a LOT more digging; still haven't quite found the root cause but feel closer. Some things that feel important:

1. During the python extension activation, we first activate the extension in an "untrusted" scenario. Then we register a callback that runs when the user clicks "Trust" that deactivates and reactivates the extension in a "trusted" scenario. I've confirmed that various classes are constructed untrusted, then disposed, and set up trusted. But ultimately when resolveEnv() is called in the trusted scenario, it's using an untrusted instance for some reason. Perhaps something isn't getting disposed correctly?
   

   positron/extensions/positron-python/src/client/extension.ts

   Lines 64 to 78 in 6d52231

   	export async function activate(context: IExtensionContext): Promise<PythonExtension> {
   	let api: PythonExtension;
   	let ready: Promise<void>;
   	let serviceContainer: IServiceContainer;
   	let isFirstSession: boolean | undefined;
   	try {
   	isFirstSession = context.globalState.get(GLOBAL_PERSISTENT_KEYS, []).length === 0;
   	const workspaceService = new WorkspaceService();
   	context.subscriptions.push(
   	workspaceService.onDidGrantWorkspaceTrust(async () => {
   	await deactivate();
   	await activate(context);
   	}),
   	);
   	[api, ready, serviceContainer] = await activateUnsafe(context, stopWatch, durations);

2. resolveEnv() is cached for 30 seconds for a given interpreter path. I'm not sure exactly what, if anything, breaks this cache. (Ex. the extension deactivating and the instance being disposed? Using a different instance? Not sure.) But in the failure scenario, the first time it's called for the relevant interpreter path is that same call I mentioned in (1) where it's using the untrusted instance after the user has clicked "Trust." So removing the cache decorator doesn't help. The question to me is why that instance is being called in the first place.
   

   positron/extensions/positron-python/src/client/pythonEnvironments/nativeAPI.ts

   Lines 551 to 556 in 6d52231

   	@cache(30_000, true)
   	async resolveEnv(envPath?: string): Promise<PythonEnvInfo | undefined> {
   	if (envPath === undefined) {
   	return undefined;
   	}
   	const native = await this.finder.resolve(envPath);

3. I just figured out that that strange untrusted call to resolveEnv() is not from the session startup code I pointed to before, but instead happens before that, when Positron is asking the python extension for its recommended interpreter. So perhaps this is closer to the code that gets stale after the user "trusts" the workspace?
   

   positron/extensions/positron-python/src/client/positron/manager.ts

   Lines 160 to 166 in 6d52231

   	async recommendedWorkspaceRuntime(): Promise<positron.LanguageRuntimeMetadata | undefined> {
   	// TODO: may need other handling for multiroot workspaces
   	const workspaceUri = vscode.workspace.workspaceFolders?.[0]?.uri;
   	const { path: interpreterPath, isImmediate } = await this.recommendedWorkspaceInterpreterPath(workspaceUri);
   	if (interpreterPath) {
   	const interpreter = await this.interpreterService.getInterpreterDetails(interpreterPath, workspaceUri);

[isabelizimm]

upstream issue: microsoft/vscode-python#23922

it looks like clearing the cache and restarting has helped folks ⏫ i'm seeing this error pop up in #7141 and #6280 as well

[austin3dickey]

Nice, thanks for finding that issue! That is definitely the cause of the PET error I mentioned above, and possibly the cause of why I couldn't get your delete/recreate PR to work: #7184 (review)

I think the issue with not disposing the PythonRuntimeManager during a trust transition might still be something separate, so #7337 will be a good independent change as well.

[jonvanausdeln]

Verified Fixed

Positron Version(s) : 2025.05.0-103
OS Version(s) : Windows 11

Test scenario(s)

Opened project right after starting and no issues. I tried several times with different projects, no issue