Skip to content

Bug: MISSING_ENVS_REPORTING_STATE is permanently exhausted after first refresh #395

@karthiknadig

Description

@karthiknadig

Summary

MISSING_ENVS_REPORTING_STATE is a process-global static AtomicU64 that, once set to MISSING_ENVS_COMPLETED by complete_missing_env_reporting(), can never be reset. Subsequent configurerefresh cycles cannot trigger missing-env reporting again.

Root Cause

In crates/pet/src/jsonrpc.rs:

  • Line 418-422: MISSING_ENVS_REPORTING_STATE is initialized to MISSING_ENVS_AVAILABLE
  • Line 715-721: complete_missing_env_reporting() sets it to MISSING_ENVS_COMPLETED via CAS
  • Line 674-676: try_begin_missing_env_reporting() returns false immediately when state is MISSING_ENVS_COMPLETED
  • handle_configure (line 473-550): increments the generation but never resets MISSING_ENVS_REPORTING_STATE

Impact

If a user reconfigures (e.g., installs conda after the first refresh), missing-env discovery is silently skipped for the rest of the server's lifetime. In the VS Code extension, this means newly installed Python environment managers won't trigger missing-env telemetry until the extension host restarts.

Proposed Fix

Reset MISSING_ENVS_REPORTING_STATE to MISSING_ENVS_AVAILABLE inside handle_configure when the generation is bumped, or use the generation number itself as the "completed" sentinel so it naturally expires when a new generation starts.

Introduced By

PR #391 (d40b4bc — fix: harden refresh generation guards)

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugIssue identified by VS Code Team member as probable bug

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions