Fix "Downloading .NET..." status bar indicator not clearing after download completes

[Copilot]

StatusBarObserver had no awareness of concurrent downloads — it hid the status bar on the first DotnetAcquisitionCompleted event received, even if other downloads were still in progress. It also never handled DotnetAcquisitionFinalError, leaving the indicator permanently visible on download failure.

Changes

• StatusBarObserver: Add inProgressDownloads: string[] tracking (consistent with OutputChannelObserver) to gate resetAndHideStatusBar() on all downloads finishing:

  • DotnetAcquisitionStart → push installId, show indicator
  • DotnetAcquisitionCompleted / DotnetInstallExpectedAbort → remove installId, hide if empty
  • DotnetAcquisitionFinalError (new) → remove installId, hide if empty (indicator was stuck forever on failure)
  • DotnetAcquisitionError → unchanged (always show error state)

• StatusBarObserver.test.ts: New unit tests covering single download lifecycle, concurrent download tracking (stays visible while any download is in progress), abort, and final-error scenarios.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• microsoft.com
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node node /home/REDACTED/work/vscode-dotnet-runtime/vscode-dotnet-runtime/vscode-dotnet-runtime-library/node_modules/.bin/mocha -u tdd -- dist/test/unit/DebianDistroTests.test.js dist/test/unit/DotnetConditionValidator.test.js dist/test/unit/DotnetCoreAcquisitionWorker.test.js dist/test/unit/DotnetPathFinder.test.js dist/test/unit/DotnetResolver.test.js dist/test/unit/ErrorHandler.test.js dist/test/unit/ExecutableArchitectureDetector.test.js dist/test/unit/ExistingPathResolver.test.js dist/test/unit/GlobalInstallerResolver.test.js dist/test/unit/InstallScriptAcquisitionWorker.test.js dist/test/unit/InstallTracker.test.js dist/test/unit/InstallationValidator.test.js dist/test/unit/IssueReporter.test.js dist/test/unit/JsonInstaller.test.js dist/test/unit/LinuxDistroTests.test.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Incorrect status "Downloading .NET" shown</issue_title>
<issue_description>### Describe the bug.

I run code-insiders . in roslyn folder of dotnet/roslyn project. Ran a test (ie. project system finished loading) and the status bar still shows "Downloading .NET".

When I click on that status, it opens that Output pane, which shows that it's no longer downloading .NET.

Please attach log file(s) here if you have any.

Sorry, I didn't find any logs matching the description above. When I look at the two folders created today in the folder you described, I only see a cli.log file:

Reproduction Steps

1. open the project
2. wait
3. status keeps showing "Downloading .NET"

Expected Behavior

I would expect "Downloading .NET" to disappear at some point or be replaced by some other more up-to-date status.

Exceptions & Errors (if any)

No response

.NET Install Tool Version

3.0.0

Your operating system? Please provide more detail, such as the version and or distro above.

Windows

VS Code Version

Version: 1.111.0-insider (user setup) Commit: 3d96350ed546b786ace7de5ff1d13ab7433073f6</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Incorrect status "Downloading .NET" shown #2605

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[nagilson]

I dont think this would properly handle 2 simultaneous requests of the same version-component-arch / install id since the id can be the same depending on that, which is the common case (c# and c#dk ask to acquire the same thing at startup) so we should see how that works (what events are published in this case, are both published or not, I think they are) + test it. otherwise seems prettysolid