Ensure that extension updates are compatible with the running Positron version

[softwarenerd]

Overview

This implementation requires setting compatible: true in the gallery query, which triggers manifest fetching for extension compatibility validation. This is necessary because the Open VSX marketplace does not expose engines.positron as a gallery metadata property (unlike engines.vscode, which is exposed via the Microsoft.VisualStudio.Code.Engine property).

Without access to engines.positron in the marketplace metadata, we must fetch the full extension manifest to read the Positron engine requirement during the browse/query flow. This ensures extensions with incompatible Positron version requirements are filtered out before being presented to users.

Trade-off: While this approach increases network overhead due to manifest fetches, it provides consistent version compatibility filtering for Positron extensions, matching the behavior users expect from VS Code's engine validation.

Release Notes

New Features

• N/A

Bug Fixes

• Positron promotes extension updates incompatible with the current version of Positron #11321 Ensures that extension updates are compatible with the running Positron version.

QA Notes

The best way to test this PR is in a dev build running locally.

First, "Disable Auto Update for All Extensions":

Next:

• Install an old version of the Quarto extension (1.111.0 is a good one to use)
• Manually vary positronVersion in product.json to older version numbers and re-run Positron to check the Extensions panel / Quarto extension to see what update is suggested.

For example:

positronVersion: "2024.06.0" will result in being prompted to update Quarto to v1.222.0:

positronVersion: "2025.06.0" will result in being prompted to update Quarto to v1.226.0:

positronVersion: "2025.12.0" (and later) will, today, anyway, result in being prompted to update Quarto to v1.130.0:

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical

^{readme  valid tags}

[juliasilge]

This is working for me great! 🚀

I notice that isPositronEngineValid() always fetches the manifest, and in cases where isEngineValid() also needs to fetch it (when the engine isn't in extension properties), we end up fetching the same manifest twice. I'd suggest restructuring so we fetch the manifest once and share it between both checks. Open VSX is soon to be implementing rate limiting in various situations, and I think we don't want to 2x the requests any of our users are making.

[jmcphers]

I added some debug logging and ran an extension search for quarto. I'm fortunate enough to have a low latency 1 gigabit fiber optic connection, but every fetch still costs ~500ms. So, loading the search results took quite a while (> 15s).

2026-03-06 16:42:34.928 [debug] [Window] Fetched manifest for yunierolivera.markdown-quarto-word-count version 1.10.0 in 525ms
2026-03-06 16:42:35.545 [debug] [Window] Fetched manifest for ntluong95.quarto-wingman version 0.1.0 in 616ms
2026-03-06 16:42:36.062 [debug] [Window] Fetched manifest for mcanouil.quarto-wizard version 2.2.0 in 515ms
2026-03-06 16:42:36.608 [debug] [Window] Fetched manifest for emilhvitfeldt.quarto-helpers version 0.1.0 in 546ms
2026-03-06 16:42:37.178 [debug] [Window] Fetched manifest for emilhvitfeldt.quarto-extension-helpers version 0.1.0 in 569ms
2026-03-06 16:42:37.647 [debug] [Window] Fetched manifest for coatless.quartize version 0.0.1 in 468ms
2026-03-06 16:42:38.116 [debug] [Window] Fetched manifest for renathossain.markdown-runner version 2.5.0 in 469ms
2026-03-06 16:42:38.624 [debug] [Window] Fetched manifest for satokaz.vscode-markdown-header-coloring version 0.2.0 in 507ms
2026-03-06 16:42:39.110 [debug] [Window] Fetched manifest for nanyeglm.markdown-preview-enhanced-plus version 0.8.20 in 485ms
2026-03-06 16:42:39.411 [debug] [Window] Fetched manifest for shd101wyy.markdown-preview-enhanced version 0.8.20 in 300ms
2026-03-06 16:42:39.713 [debug] [Window] Fetched manifest for takumii.markdowntable version 0.10.4 in 302ms
2026-03-06 16:42:39.993 [debug] [Window] Fetched manifest for yzhang.markdown-all-in-one version 3.6.2 in 279ms
2026-03-06 16:42:40.515 [debug] [Window] Fetched manifest for zokugun.markdown-ranking-table version 0.1.0 in 520ms
2026-03-06 16:42:41.077 [debug] [Window] Fetched manifest for vv13.markdown-auto-preview version 0.3.4 in 561ms
2026-03-06 16:42:41.561 [debug] [Window] Fetched manifest for we0m.markdown-list version 1.0.0 in 483ms
2026-03-06 16:42:42.065 [debug] [Window] Fetched manifest for zokugun.markdown-table-sort version 0.1.0 in 503ms
2026-03-06 16:42:42.397 [debug] [Window] Fetched manifest for ra-jeev.write-assist-ai version 0.7.2 in 332ms
2026-03-06 16:42:43.115 [debug] [Window] Fetched manifest for tomchen.paste-markdown-link version 1.1.0 in 716ms
2026-03-06 16:42:43.588 [debug] [Window] Fetched manifest for caenrigen.jupytext-sync version 1.4.4 in 472ms
2026-03-06 16:42:43.885 [debug] [Window] Fetched manifest for ltex-plus.vscode-ltex-plus version 15.6.1 in 296ms
2026-03-06 16:42:44.459 [debug] [Window] Fetched manifest for hugoblox.hugoblox-studio version 0.19.2 in 572ms

In addition to the OpenVSX load, I think these numbers will be bad enough on the median internet connection that some features will feel like they are just not working. We may need to strike a balance between being correct and being fast.

Since the goal here is to avoid suggesting updates that are incompatible, maybe we can do something closer in proximity to the update suggestion? Or even (I know it's gross) just use this fetch during an update attempt to provide a detailed message? (Sorry, you can't update because you need Positron 2026.10, you're on 2026.09)

[juliasilge]

Closed by #12417