Summary
Issue #383 changed refresh to run against a transient locator graph and then copy back the shared state that later JSONRPC requests still depend on. We currently do that explicitly for Conda and Poetry, but there is no general contract for which locator state is allowed to matter after a refresh completes.
That is fragile: future locator changes can silently regress resolve, find, or telemetry behavior if a locator starts depending on refresh-populated state and nobody also adds a handoff step.
Current examples
Conda keeps discovered environments/managers that are later used by condaInfo and missing-env telemetry.Poetry keeps a cached search_result that improves later resolve fidelity.- Other locators also keep mutable state, but under different assumptions:
PipEnv stores the configured executable.Uv stores configured workspace directories.WindowsRegistry caches search_result, but can self-hydrate on demand.LinuxGlobalPython caches discovered executables for reuse/perf.
The current code has no explicit distinction between:
- config-only state
- refresh-discovered state that must survive for correctness
- performance caches that may be recomputed
Problem
Right now the server logic effectively knows about stateful locators by name. That makes the refresh pipeline harder to reason about and increases the chance that a future locator will accidentally depend on stale or missing state after a transient refresh.
Proposed direction
Audit all locators and define an explicit contract for post-refresh state, for example by doing one of the following:
- Make locators fully stateless apart from configured inputs.
- Make stateful locators self-hydrating on
try_from() / later requests.
- Introduce an explicit interface for state that must be synchronized from transient refresh locators back into the long-lived shared locators.
Acceptance criteria
- Inventory locator state across the current locator set.
- Classify each piece of state as config-only, correctness-critical post-refresh state, or perf-only cache.
- Pick and document the intended contract.
- Add tests covering at least one non-Conda/Poetry stateful locator path so regressions are easier to catch.
Related
Summary
Issue #383 changed
refreshto run against a transient locator graph and then copy back the shared state that later JSONRPC requests still depend on. We currently do that explicitly for Conda and Poetry, but there is no general contract for which locator state is allowed to matter after a refresh completes.That is fragile: future locator changes can silently regress
resolve,find, or telemetry behavior if a locator starts depending on refresh-populated state and nobody also adds a handoff step.Current examples
Condakeeps discovered environments/managers that are later used bycondaInfoand missing-env telemetry.Poetrykeeps a cachedsearch_resultthat improves laterresolvefidelity.PipEnvstores the configured executable.Uvstores configured workspace directories.WindowsRegistrycachessearch_result, but can self-hydrate on demand.LinuxGlobalPythoncaches discovered executables for reuse/perf.The current code has no explicit distinction between:
Problem
Right now the server logic effectively knows about stateful locators by name. That makes the refresh pipeline harder to reason about and increases the chance that a future locator will accidentally depend on stale or missing state after a transient refresh.
Proposed direction
Audit all locators and define an explicit contract for post-refresh state, for example by doing one of the following:
try_from()/ later requests.Acceptance criteria
Related