Cross-session cache misses on every fresh remote (SSH / WSL / dev container / codespace)

[eleanorjboyd]

Problem

The cross-session cache for the discovered global system Python (PR #1455) lives in context.globalState. In remote scenarios, context.globalState is scoped to the remote machine, not the local one. As a result, the cache never primes on a fresh remote and every first connection to a new SSH host, dev container, codespace, attached container, or WSL distro starts cold and falls through to a full PET refresh on the foreground env-selection path.

This also affects the local case any time globalState is wiped (e.g. extension reinstall, profile reset).

Current behavior

• getSystemEnvForGlobal() / setSystemEnvForGlobal() read/write SYSTEM_GLOBAL_KEY via getGlobalPersistentState(), which wraps context.globalState.
• getGlobalPersistedPath is wired into tryFastPathGet (fastPath.ts) for the system-Python path. When globalState is empty the fast path returns undefined and registration falls through to the slow path.
• Workspace-scoped paths use setSystemEnvForWorkspace / getSystemEnvForWorkspace, which write to context.workspaceState (keyed on workspace folder fsPath) — that path is unaffected.

Why it matters

Every time a user connects VS Code to a new remote (or reopens after the remote globalState is reset), the foreground env-selection path waits on a fresh PET refresh instead of validating a cached path. This is the dominant remaining hang scenario on Linux based on our most recent investigation, and ssh-remote, WSL, and dev-containers are all affected.

Acceptance criteria

• On a workspace where the global system Python has been resolved at least once, opening the same workspace folder in a fresh VS Code session on the same remote hits the cache without a PET refresh.
• On a brand-new workspace folder on the same remote, behavior is unchanged from today (cache miss → PET refresh).
• On a brand-new remote with a brand-new workspace folder, behavior is unchanged from today (option 1 doesn't claim to fix this case — option 2/3 would).
• No regression to existing telemetry: global_env.cache continues to emit hit / miss / stale correctly.
• No regression to the workspace-scoped fast-path (getSystemEnvForWorkspace users).
• Unit tests covering: workspaceState-primary lookup, fallback to globalState, both write paths, and stale-path invalidation through both layers.

Related

• PR Cross-session cache for discovered system Python path #1455 — original cross-session cache.
• PR feat: add local existence check for persisted paths in fast-path resolution #1564 — cheap fs.access check on persisted paths in fast-path resolution. (this helped fix the regression which the prior PR introduced)