Fix stale Pylance resolution in cached builds - #8588
Merged
StellaHuang95 merged 3 commits intoJul 23, 2026
Conversation
Refresh registry metadata when resolving latest Pylance versions, while preserving cached package downloads. Quote and scope dynamic cache key segments so explicit dotted versions work and stable/preview cache fallbacks do not cross channels. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 42f01b56-f94e-4760-8e1d-d0893ff82b26
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
🔒 Automated review in progress — @heejaechang is auto-reviewing this PR. |
Contributor
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request updates the Azure Pipelines restore flow to prevent stale Pylance “latest/preview” resolution when npm caches are restored between builds, while keeping the performance benefits of cached installs.
Changes:
- Adjust Cache@2 keys/restore keys so node/npm caches are segmented by Pylance version + release channel and dotted version strings are treated as literals.
- Force
npm view(used only for resolvinglatest) to refresh registry metadata even when CI setsnpm_config_prefer_offline=true. - Quote debugpy version in the PyPI wheels cache key to avoid Cache@2 interpreting dotted versions as file paths.
Show a summary per file
| File | Description |
|---|---|
| Build/templates/restore_packages.yml | Refines cache keys to avoid cross-channel restores and to correctly treat version tokens as literals. |
| Build/PreBuild.ps1 | Ensures npm view refreshes registry metadata when resolving latest under offline-preferring CI settings. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Low
Pylance 2026.3.1 and current previews require Node 24. Select a compatible Node runtime before the shared package restore so npm does not emit an unsupported-engine error under the agent default Node 12. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 42f01b56-f94e-4760-8e1d-d0893ff82b26
Contributor
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
npm 11 no longer recognizes always-auth and writes a warning to stderr for every command. npmAuthenticate continues to provide registry-scoped credentials, so remove the unsupported project setting to keep the restore task error-free under Node 24. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 42f01b56-f94e-4760-8e1d-d0893ff82b26
|
rchiodo
approved these changes
Jul 23, 2026
Contributor
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue
PTVS nightly builds have remained on Pylance
2025.12.104even though newer stable and prerelease versions were published and available in themsft_consumptionfeed. For example, build 14744946 requestedlatest/previewbut selected and installed2025.12.104.The behavior started after the caching changes in #8418. The cache landed on February 26, 2026;
2026.1.100reached the feed on February 27, but the February 28 nightly and every later nightly continued selecting2025.12.104.Root cause
npm_config_prefer_offline=trueto accelerate installs. That also affectednpm view, causing it to bypass staleness checks and read an old cached package-version catalog.2025.12.104continued to be restored even after newer versions reached the feed.2026.3.1were inserted into Cache@2 keys without quotes. Cache@2 interpreted the dotted value as a file path and failed withFile not found: 2026.3.1before package restoration began. The same issue applied to explicit debugpy versions.The pyrx publication path itself is healthy: newer versions are present in
msft_consumption, and the release pipeline successfully queued PTVS with the exact released version.Fix
npm viewto refresh registry metadata when resolvinglatest, while retaining the npm cache for package downloads.package.jsonsegment and keep partial cache restores within the same requested channel.With the current feed contents, the corrected lookup resolves stable
2026.3.1and preview2026.2.109. Future releases will be discovered from the feed rather than from stale cached metadata.Validation
npm_config_prefer_offline=true; the command-level freshness override resolved stable2026.3.1and preview2026.2.109.Follow-up: Node 24 requirement
PR build 14750001 confirmed that fresh resolution works: it selected and installed Pylance
2026.3.1. The restore task then failed because the agent supplied Node12.22.12, while current Pylance packages declareengines.node >=24. npm wrote the unsupported-engine warning to stderr, and PowerShell@1 treated that output as a task error despite npm exiting successfully.The shared restore template now selects Node
24.xbefore invoking npm. This satisfies the current stable and preview Pylance packages instead of suppressing a genuine compatibility warning.npm 11 also exposed the repository's obsolete
always-auth=trueproject setting. npm 11 reports it as an unknown configuration on stderr, which caused the same PowerShell task failure after the Node upgrade. The setting has been removed;npmAuthenticate@0continues to inject registry-scoped credentials.PR build 14750412 validates the complete fix: Node 24 setup succeeded,
Restore packagescompleted successfully, Pylance2026.3.1was installed, and debugpy1.8.21was installed without npm configuration or engine warnings.