fix: cap pre-release versions returned by extensionQuery

[netomi]

What

extensionQuery (/vscode/gallery/extensionquery) fetches every active version of every requested extension when FLAG_INCLUDE_VERSIONS or FLAG_INCLUDE_VERSION_PROPERTIES is set. For an extension whose pre-release channel publishes one build per commit, that history can grow into the thousands, making the query and the response needlessly expensive.

Regular releases are left completely untouched. Active pre-release versions are now capped to the most recent N per extension (combined across all of its target platforms), ranked by the same semver-based ordering ExtensionVersion.SORT_COMPARATOR uses for "latest" - so the true latest pre-release (rank #1) can never be dropped by the cap, and downstream "latest version" computations stay correct.

How

The cap is a plain method parameter threaded through:

LocalVSCodeService -> RepositoryService.findActiveExtensionVersions -> ExtensionVersionJooqRepository.findAllActiveByExtensionIdAndTargetPlatform

configured on LocalVSCodeService via ovsx.extension-query.max-pre-release-versions (default 100). A negative value (e.g. -1) disables the cap entirely, matching the "negative means unlimited" convention already used for ovsx.data.mirror.requests-per-second.

Implementation detail: the SQL adds a correlated-subquery condition (EXTENSION_VERSION.PRE_RELEASE.isFalse().or(isAmongLatestPreReleases(limit))) rather than a window-function/derived-table rewrite, since the existing flat query's generic toExtensionVersion row mapper can't safely be reused once wrapped in a derived table (duplicate NAMESPACE.ID/EXTENSION.ID/EXTENSION_VERSION.ID column names collide once re-selected).

Testing

ExtensionVersionJooqRepositoryTest gains coverage for:

• capping pre-releases while leaving all stable releases untouched
• capping across an extension's target platforms combined, not per platform
• the target-platform filter being applied after the cross-platform cap (so a platform-scoped request can see fewer versions than exist for that platform)
• honouring a caller-supplied limit rather than a value fixed in the repository
• a negative limit disabling the cap entirely

Existing call sites/mocks (LocalVSCodeServiceTest, VSCodeAPITest, RegistryAPITest, RepositoryServiceSmokeTest) updated for the new parameter.

[Copilot]

Pull request overview

This PR introduces a configurable cap on how many active pre-release channel versions are returned by the VS Code extensionQuery path, to prevent queries/responses from growing unbounded when pre-release channels publish very frequently, while leaving stable releases unaffected.

Changes:

• Thread a maxPreReleaseVersions parameter through LocalVSCodeService -> RepositoryService -> ExtensionVersionJooqRepository.
• Implement repository-side filtering to limit active pre-release versions per extension (cross-platform combined), with a negative value disabling the cap.
• Add/adjust tests and mocks to cover the new behavior and updated method signature.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
server/src/main/java/org/eclipse/openvsx/adapter/LocalVSCodeService.java	Adds configurable ovsx.extension-query.max-pre-release-versions and passes it into repository query.
server/src/main/java/org/eclipse/openvsx/repositories/RepositoryService.java	Extends findActiveExtensionVersions to accept maxPreReleaseVersions.
server/src/main/java/org/eclipse/openvsx/repositories/ExtensionVersionJooqRepository.java	Adds SQL-side pre-release capping logic.
server/src/test/java/org/eclipse/openvsx/repositories/ExtensionVersionJooqRepositoryTest.java	Adds coverage for pre-release capping semantics (stable untouched, cross-platform cap, negative disables).
server/src/test/java/org/eclipse/openvsx/repositories/RepositoryServiceSmokeTest.java	Updates smoke test call site for new method signature.
server/src/test/java/org/eclipse/openvsx/adapter/LocalVSCodeServiceTest.java	Updates mocks for new repository method signature.
server/src/test/java/org/eclipse/openvsx/adapter/VSCodeAPITest.java	Updates mocks for new repository method signature.
server/src/test/java/org/eclipse/openvsx/RegistryAPITest.java	Updates mocks for new repository method signature.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (2)

server/src/main/java/org/eclipse/openvsx/adapter/LocalVSCodeService.java:99

• The PR description says ovsx.extension-query.max-pre-release-versions defaults to 100, but the code currently defaults to -1 (unlimited). This is a behavioral mismatch: with -1 the cap is disabled unless operators opt in, which contradicts the stated default and the PR’s stated purpose of reducing expensive queries/responses by default.

    // fetches per extensionQuery request; regular releases are never capped. A negative value
    // (e.g. the -1 default) disables the cap entirely, preserving the pre-existing unbounded
    // behaviour unless an operator opts into capping.
    @Value("${ovsx.extension-query.max-pre-release-versions:-1}")
    int maxPreReleaseVersions;

server/src/test/java/org/eclipse/openvsx/repositories/ExtensionVersionJooqRepositoryTest.java:222

• This comment says the cross-platform cap is applied before the “win32-x64 filter below”, but the test actually requests linux-x64 only. The wording is misleading when reading the test intent.

        // 99 higher-semver win32 pre-releases crowd out all but the newest of the 2 linux
        // pre-releases from the cross-platform top-100 cap, before the win32-x64 filter below is
        // even applied - so requesting linux-x64 only can see fewer than 100 versions even though
        // more than 100 exist for the extension overall.