Silence orphaned unhandledRejections from extension management

[bryanchen-d]

What

Silence two boot-time / race-condition paths in the shared-process extension management service that produce orphan unhandledRejection events, surfacing as unhandlederror-Cannot read the extension from ... telemetry buckets.

These rejections carry no new diagnostic information — the underlying install failure is already reported by the primary install task (extensionGallery:install event with the real error, stack, and extension id) or logged by the cleanup/migrate flows themselves.

Two paths fixed

1. Duplicate-install wait promise — abstractExtensionManagementService.ts

When a second install request races for an extension that's already being installed (very common at boot for github.copilot-chat because it gets re-requested by auto-update + restore + sync), a sibling promise is created via Event.toPromise(onDidInstallExtensions).then(...) and pushed into alreadyRequestedInstallations.

It's awaited on the success path (line 451), but if the outer try throws first (e.g. another extension in the same batch fails) control jumps to catch and the sibling promise is never observed → Node fires unhandledRejection.

Fix: attach a no-op rejection handler on a separate handle so the rejection is always observed. The original promise is still awaited via joinAllSettled on the happy path, and the underlying failure is already surfaced through the primary task's installExtensionResultsMap entry.

2. Fire-and-forget startup tasks — sharedProcess/contrib/extensions.ts

extensionManagementService.cleanUp();        // not awaited, no .catch
this.migrateUnsupportedExtensions();          // not awaited, no .catch

Any rejection becomes an unhandled rejection at sharedProcess boot. Both functions already log their own internal failures (and migrateUnsupportedExtensions wraps each installFromGallery in its own try/catch), so the only thing missing is a top-level .catch(logService.error) to swallow the orphan.

Why not just fix scanLocalExtension?

The throw inside scanLocalExtension is correct — the caller asked to read an extension that isn't where the caller said it would be (a separate path-construction bug producing //ext-id-style URIs that still needs investigation). Wrapping it would silently corrupt install state. The right fix is at the unawaited consumers.

Impact

Removes the entire unhandlederror-Cannot read the extension from ... family from the top error buckets (~7M machines / ~120M hits in the 14d window) without losing any diagnostic signal — user-initiated install failures still produce notifications and extensionGallery:install telemetry as before.

[Copilot]

Pull request overview

This PR addresses boot-time race conditions in extension management that can lead to orphaned unhandledRejection events (notably the unhandlederror-Cannot read the extension from ... telemetry family), without suppressing the underlying install/cleanup error reporting that already exists elsewhere in the pipeline.

Changes:

• Prevents orphaned rejections when waiting on a duplicate/overlapping extension install by attaching a no-op rejection handler to the “wait for install completion” promise.
• Ensures shared-process startup tasks (cleanUp, unsupported-extension migration) are not able to surface as unhandled rejections by adding top-level .catch(...) logging.

Show a summary per file

File	Description
src/vs/platform/extensionManagement/common/abstractExtensionManagementService.ts	Adds a rejection handler to the duplicate-install “wait” promise so failures can’t become orphaned unhandledRejections if the outer flow exits early.
src/vs/code/electron-utility/sharedProcess/contrib/extensions.ts	Adds .catch(...) logging to fire-and-forget startup tasks to prevent shared-process boot-time unhandled rejections.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 0

[Copilot]

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 0 new

[vs-code-engineering]

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

@deepak1556

Matched files:

• src/vs/code/electron-utility/sharedProcess/contrib/extensions.ts