Skip to content

Bug: MISSING_ENVS_REPORTING_STATE is permanently exhausted after first refresh #395

Description

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)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugIssue identified by VS Code Team member as probable bug

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions