fix(vscode): Updated bundle feed to use index.json instead of index-v2.json #8807
Conversation
🤖 AI PR Validation ReportPR Review ResultsThank you for your submission! Here's detailed feedback on your PR title and body compliance:✅ PR Title
✅ Commit Type
|
| Section | Status | Recommendation |
|---|---|---|
| Title | ✅ | Keep as-is. |
| Commit Type | ✅ | No change needed. |
| Risk Level | Add the matching repo label (e.g., risk:low). Remove needs-pr-update after update. |
|
| What & Why | ✅ | Good. |
| Impact of Change | Call out the changed function signatures and ensure callers updated. | |
| Test Plan | ✅ | Unit tests present; ensure CI passes. |
| Contributors | Optional: add contributors if any. | |
| Screenshots/Videos | Not applicable. |
Final Notes & Action Items
- Please add the appropriate risk label matching the PR body (recommended:
risk:low). The PR currently lacks a risk label — add one and removeneeds-pr-updateonce done. - Verify that all call sites were updated for the changed function signatures:
- addDefaultBundle(context, hostJson) -> addDefaultBundle(hostJson) (context parameter removed). Search the repo for usages and update them as needed.
- getLatestVersionRange(context) -> getLatestVersionRange() (now synchronous and returns defaultVersionRange). Ensure any callers expecting a Promise were updated.
- Confirm CI passes for the added unit tests and any integration pipelines that might rely on the old async behavior.
- (Optional) Expand the Impact section in the PR body to mention the function signature changes so reviewers can easily spot possible breaking changes for developers.
Please update the PR with the label and any notes about call-site updates, then re-submit. Thank you for the clear title, tests, and concise PR body — overall this looks good and low risk.
Last updated: Wed, 11 Feb 2026 00:41:03 GMT
There was a problem hiding this comment.
Pull request overview
Updates the VS Code designer’s extension-bundle feed usage to rely on index.json (instead of index-v2.json) and avoids fetching the default bundle version range from the feed by using the in-repo constant.
Changes:
- Switch workflow bundle feed URL to
.../index.jsonand update the “latest bundle version” selection logic accordingly. - Remove the network-based “latest version range” lookup;
getLatestVersionRange()andaddDefaultBundle()now usedefaultVersionRange. - Add unit tests covering the new
getLatestVersionRange()andaddDefaultBundle()behavior.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| apps/vs-code-designer/src/app/utils/bundleFeed.ts | Switches to index.json, removes index-v2.json feed usage for default version range, and adjusts version selection from feed results. |
| apps/vs-code-designer/src/app/utils/test/bundleFeed.test.ts | Adds tests for getLatestVersionRange() and addDefaultBundle(). |
| async function getWorkflowBundleFeed(context: IActionContext): Promise<string[]> { | ||
| const envVarUri: string | undefined = process.env.FUNCTIONS_EXTENSIONBUNDLE_SOURCE_URI; | ||
| const baseUrl: string = envVarUri || 'https://cdn.functions.azure.com/public'; | ||
| const url = `${baseUrl}/ExtensionBundles/${extensionBundleId}/index-v2.json`; | ||
| const url = `${baseUrl}/ExtensionBundles/${extensionBundleId}/index.json`; | ||
|
|
||
| return getJsonFeed(context, url); | ||
| } |
There was a problem hiding this comment.
getWorkflowBundleFeed is typed to return Promise<string[]>, but it directly returns getJsonFeed(context, url). getJsonFeed is constrained to T extends Record<string, any> (i.e., JSON object), so this is very likely a type error and/or a runtime mismatch if index.json is an object (as the existing IBundleFeed model suggests). Consider fetching index.json into a typed object (e.g., IBundleFeed or a dedicated IIndexJsonFeed), then explicitly deriving the version list from a known property (and keep the function return type aligned with what index.json actually contains).
| const feedVersions: string[] = await getWorkflowBundleFeed(context); | ||
| for (const bundleVersion of feedVersions) { | ||
| latestFeedBundleVersion = semver.gt(latestFeedBundleVersion, bundleVersion) ? latestFeedBundleVersion : bundleVersion; | ||
| } |
There was a problem hiding this comment.
downloadExtensionBundle assumes every entry returned from the feed is a valid semver and passes it directly to semver.gt. If any non-semver value makes it into the returned list (e.g., because the feed shape changes or contains metadata), semver.gt can throw and the whole download path will fall into the catch and silently skip updating. Consider filtering/validating feed entries with semver.valid (and/or extracting versions from a well-defined feed object) before comparing.
| /** | ||
| * Gets latest bundle extension version range. | ||
| * @param {IActionContext} context - Command context. | ||
| * @returns {Promise<string>} Returns lates version range. | ||
| * @returns {string} Returns latest version range. | ||
| */ | ||
| export async function getLatestVersionRange(context: IActionContext): Promise<string> { | ||
| const feed: IBundleFeed = await getBundleFeed(context, undefined); | ||
| return feed.defaultVersionRange; | ||
| export function getLatestVersionRange(): string { | ||
| return defaultVersionRange; | ||
| } |
There was a problem hiding this comment.
getLatestVersionRange now returns the defaultVersionRange constant unconditionally, but its name/JSDoc still reads like it computes the latest value. This is misleading for callers and makes it easy to assume it’s dynamically sourced. Consider renaming it (e.g., to reflect that it returns the default/fallback range) and/or updating the doc comment to explicitly state it no longer queries the feed.
| logLevel: { | ||
| default: 'Information', |
There was a problem hiding this comment.
In the "should preserve other host.json properties" test, hostJson is typed as IHostJsonV2 but the logging object you provide uses logLevel.default, which doesn’t match the IHostJsonV2['logging'] shape (it expects applicationInsights.samplingSettings...). This will fail type-checking; either use a property that exists on IHostJsonV2 (e.g., managedDependency, extensions, or the supported logging.applicationInsights structure) or relax the test’s typing for that specific case.
| logLevel: { | |
| default: 'Information', | |
| applicationInsights: { | |
| samplingSettings: { | |
| isEnabled: true, | |
| }, |
1 participant
Commit Type
Risk Level
What & Why
Our current use of bundle feed is using index-v2.json which has not been updated in a while. Updating to use and pull the latest version from index.json
Impact of Change
Test Plan
Contributors
Screenshots/Videos