/vscode/unpkg returns 404 for bundled web-extension resources present in the published VSIX (breaks web extensions that load bundled assets at runtime)

[rfried]

Summary

On open-vsx.org, /vscode/unpkg/.../extension/<path> returns 404 for arbitrary bundled files in a web extension, even though those files are present in the published .vsix. The extension's declared browser entry serves fine, but any other bundled file (a media/ tree of Pyodide + Python wheels) 404s — so a web extension that reads its bundled assets at runtime cannot start on any Open VSX–backed host (GitLab Web IDE, Cursor, Gitpod, code-server). The identical VSIX works on the MS Marketplace (vscode.dev, GitHub Codespaces), so the package is correct and the difference is purely the registry's resource serving.

This looks like the same class of problem as #1552, #432, #1131, and #1680, and relates to #1301 — filing a concrete, current repro since those are closed.

Repro (extension pragmatest.lvkit, web target, v0.7.2)

Served (200):

https://open-vsx.org/vscode/unpkg/pragmatest/lvkit/0.7.2/extension/dist/web/extension.js   -> 200
https://open-vsx.org/vscode/unpkg/pragmatest/lvkit/0.7.2/extension/package.json            -> 200

Not served (404) — but present in the VSIX:

.../0.7.2/extension/media/wheels/manifest.json                -> 404   (101 bytes)
.../0.7.2/extension/media/wheels/lvkit-0.7.2-py3-none-any.whl  -> 404
.../0.7.2/extension/media/pyodide/pyodide.mjs                 -> 404

Confirmed the files are in the published package (downloaded pragmatest.lvkit-0.7.2@web.vsix, 12.8 MB, unzip -l):

extension/media/wheels/manifest.json
extension/media/wheels/lvkit-0.7.2-py3-none-any.whl
extension/media/pyodide/pyodide.mjs
extension/dist/web/extension.js

Reproduces identically on 0.7.0, 0.7.1, and 0.7.2.

Runtime symptom (GitLab Web IDE, via Open VSX)

ERROR (engine assets): FileSystemError
    at Object.readFile (...extensionHostWorker...)
    at async wheelUris (.../0.7.2/extension/dist/web/extension.js)

The extension host calls vscode.workspace.fs.readFile(extensionUri + 'media/wheels/manifest.json'), which resolves to the 404 URL above. On vscode.dev (MS Marketplace) the same call succeeds and the extension starts.

Expected

Per WebResourceService.getWebResource (master), the endpoint opens the download VSIX and does zip.getEntry(name) with no path allow-list, and the size cap (ovsx.caching.files-webresource.max-file-size) defaults to -1 (disabled, with a comment noting bundled WASM can legitimately be large). So extension/media/wheels/manifest.json — a 101-byte entry that's demonstrably in the VSIX — should serve exactly like dist/web/extension.js.

Questions

1. Does open-vsx.org's /vscode/unpkg/ support serving arbitrary bundled files, or only "known" assets (FileResource types: manifest / readme / icon / license / changelog / vsixmanifest / download) plus whatever is hot in cache? FileResource.java has no type for arbitrary bundled resources.
2. If arbitrary resources are supported, why does the tiny media/wheels/manifest.json 404 while dist/web/extension.js serves, both from the same VSIX?
3. Is there a recommended way for a web extension to ship large bundled runtime assets (a self-hosted Pyodide + wheels, ~12 MB) so they load reliably on Open VSX hosts?

Happy to provide the VSIX, more URLs, or a minimal repro extension.

[netomi]

The main problem here it seems is that the /vscode/unpkg endpoint does not take a targetPlatform as argument. So what it does internally is get the first matching extension version and try to serve the respective files from that extension. In the case of pragmatest.lvkit-0.7.2 that will be the Linux X64 version, which does not have the given path in it and thus results in a 404 status.

Now I do not have an reference to the origins of that endpoint unfortunately or any reference to usages of this endpoint, but I assume also from your description that it is used to serve content for web extensions. However, the way this endpoint is implemented currently would not scale in any case. Could you explain your use-case / affiliation? Fully supporting web extensions like the VSC Marketplace does for open-vsx.org would be a bigger change afaict.