Change:
this._isOpenKey.set(true); } catch (e) { if (!cts.token.isCancellationRequested) { <del> this.notificationService.error(localize('testCoverageError', 'Failed to load test coverage: {}', String(e))); </del> <ins> this.notificationService.error(localize('testCoverageError', 'Failed to load test coverage: {0}', String(e))); </ins> } return; }

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.86.0-insider Commit: Date: 2023-12-11T05:36:45.890Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code-Insiders/1.86.0-insider Chrome/118.0.5993.159 Electron/27.1.3 Safari/537.36 Hi Sorry I cannot reproduce this issue via the extension sample. Basically, I feed the test coverage provider with the file coverages. And the test coverage view shows them. And I'm sure that is enabled. What could be the reason causing that? !
I'm guessing this is because the URIs on files in your coverage don't match precisely with the URIs of files in the workspace. Can you verify whether this is the case?
I think the uri should be correct because when I click the file in coverage view, the editor will open the correct file. !
I think I found the cause. Previously, the uri string is returned from Language Server, I parse the Uri instance by using After that, the property of the uri is Then I changed the code to After that, I found the property become: . Note that the device name become lower case (I'm on a windows machine) I feel that this requirement is too implicit. can we handle it at VS Code side? Since both of the uri are valid.
Ah, yes, that's my bug. Thanks for the investigation.

Hi My teammate tried the coverage feature today and found some really strange behavior, and it looks like related with the uri treatment. We debugged the code and can ensure that all the uri returned to VS Code are using lower case as the device name. The version info listed below: Version: 1.86.0-insider (user setup) Commit: Date: 2023-12-14T05:36:50.991Z Electron: 27.1.3 ElectronBuildId: Chromium: 118.0.5993.159 18.17.1 V8: 11.8.172.18-electron.0 OS: Windows_NT x64 10.0. first video shows that only one file's uri keeps lower case as the device name. Other files' uri become to upper case : video shows that for the second run, the coverage explorer kind of empty that nothing displays after expanding third video shows when clicking on first node, the second node gets expanded. Looks like the status of the explorer goes into a strange status.
Thanks for the followup, this should be fixed in the next Insiders. I think we have one more of those before pausing builds for the holidays...
Thank you for the quick response
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
can we get some steps to verify?
on a case-insensitive system the test profile sample on the URI before parsing it here the extension and run tests with coverage. Verify you see bars in the Explorer view.