Question:
Workaround This is an issue in Chromium itself. For now there are the following two workarounds: ### <blockQuote</blockQuote1. ### <blockQuote</blockQuote## Bug <!-- 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. -- <!-- 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. --1. ### VS Code Version Per: affected version is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.82.0-insider Commit | Date | 2023-08-11T17:10:45.392Z Electron | 25.4.0 ElectronBuildId | Chromium | 114.0.5735.248 | 18.15.0 V8 | 11.4.183.27-electron.0 OS | Linux x64 6.4.9-1-default </blockQuoteHowever, per: that , that is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.81.1 Commit | Date | 2023-08-09T22:18:39.991Z Electron | 22.3.18 ElectronBuildId | Chromium | 108.0.5359.215 | 16.17.1 V8 | 10.8.168.25-electron.0 OS | Linux x64 6.4.9-1-default snap ### OS Version <blockQuote</blockQuote</details## Steps to Reproduce 1. The GUI is invisible: the menubar continues to operate correctly.
82 updated to Electron 25 and doesn't work on older OS.
I'm using cpe:/o:opensuse:tumbleweed:, which updated 2600 packages yesterday (which I have installed) yet this problem remains. Nobody in their right mind would consider that to be old. Additionally, I am using which means that no independent part of the OS should be considered old. This is the most bleeding edge system for miles. Regardless, should I perhaps open a linked issue at
Oh, sorry, I thought it's an old OS issue. Before reporting in the electron repo, what is Help Toggle Developer Tools bringing up? Have you tried to do a clean reinstall of VSCode Insider? Perhaps it was just a bad build. Or, alternatively, you could try to download the latest Insider installer and install over your existing broken version (which I assume it's 3-4 days older than what you'd get right now) - that should effectively update it.
No problem. Thanks. Apologies for being curt. ! ! Appears that it's reproducible.
Very strange, indeed. I'm out of ideas. Would be interesting to be able to test with a previous Insider version, but for that you would need to have the old package and disable automatic updates. Electron was updated from 22 to 25 on August 8, so the last version with Electron 22 is the Insider from August 7, which is also the last version that I've tested and still working on Windows 7. Anything after that doesn't start anymore on Win 7. I'm not sure whether the Electron update on August 8 is causing your issue, though...
does the log file explain anything? To me, it seemed a little too verbose to be of much use. I can try other methods to get relevant diagnostic data if you are able to instruct me.
I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [(48)] (checkLinkStatus): Program link or binary loading failed with no info log. [(81)] Skia shader compilation error Found these: So it's definitely something related to the new Chromium included in Electron 25 and these issues seem relatively recent. The first link recommends to disable hardware acceleration, you could try searching how to do that from command line in the new Insider. Unfortunately, I don't have the time to dig deeper right now.
per , do you know whether VSCode contains a directory? I haven't been able to locate it.
remediates the problem. Because indeed this issue is dependent upon , before this update is rolled out, there needs to be remediating measures (or the update needs to be temporarily halted) lest it break a great many peoples' installations.
Can you please take a look at this? It's Chromium/Electron 25 related, so I immediately thought of you. Please see the response just above for a possible solution. Thanks!
Thanks for investigating the issue, given there are workarounds in place this is not necessarily a release blocker. I will wait for chromium to address this issue and backport the fix to Electron 25.
could a patch at least be to the affected releases to delete the relevant directory? Surely users shall be affected otherwise? I doubt we can expect them to diagnose a known issue if the solution is so simple.
We don't want to delete the GPUCache for all users and the affected scenario described in is not possible to detect from the application layer. I think the best I can do is to add this issue to the release notes and document the workarounds for visibility.
Why?
It will have impact on startup performance, for now I would wait to see the impact of this issue across our users and decide on a fix forward. The upstream issue has also been open for a while now, signifying its low impact.
Just happened again. !
This is mentioned in the 1.82 release notes I guess the issue remains in 1.83-insiders, haven't tried it yet.
It appears weird to me that solely VSCode appears to be affected by this (on my system) because Discord has been very happily updating frequently, and obviously has its own Electron-provided directory. !
Related on Stack Overflow: Related on Reddit: ,
Got this installed via fedora yesterday This wasted quiet some time on my end, as I first went searching for changes to fedora itself and finding this issue on vscode wasn't trivial.
Leaving this here for future me, as I now have that problem on a different PC
This also happens for other Electron based programs like Element and also chromium and firefox. see
I'd disagree, . It doesn't read like pragmatism - more like "didn't want to do a good fix". Startup time after the workaround felt normal. Super aggravating that this wasn't resolved with a one-time installation task to clear the GPU cache. Hard to know the aggregate cost incurred by people encountering this issue, but "not small" is probably an underestimation. Linked-issue count wouldn't be a good proxy for that metric, in that product-support's practice as shown in seems to be linking to the known-issue buried in the release notes, not to this issue. Sorry for the flames, but there you have it. When one's coding environment gets fsck'd, it's no fun, and erodes trust. Please consider.
I, for one, find great enjoyment in my coding environments.
This issue has reemerged with the latest version 1.82.3 for Ubuntu 20.04.1: Removing after the upgrade still works to get vscode running
It occurs for me almost every update of the package. It's ridiculous.
Same.
As mentioned before, this is caused by the new update in VSCode I have personally reverted to until this issue is properly solved
I was under the impression from the chromium bug that this is one time change and not required for every startup. I see that you are using snap version of VSCode, can you check if you are required to delete the cache for every start using the instead ?
I must rectify my comment: with the snap of version v1.82.1, it was required to clear the cache every startup, with v1.82.2 I don't remember having to do it, while with v1.82.3 it was needed only once on upgrade. I will edit my previous comment to fix it.
We had a runtime version bump between to , which seems like a trigger in the snap case. Can you setup deb package, we will have release this week. It would be good to confirm if updating requires to clear the cache in the deb package as well.
For what it's worth, I haven't encountered it on the rpm again
I've tried the following: removing v1.82.3 (snap) and installing v1.82.3 (deb) did require clearing the cache. removing v1.82.3 (deb) and installing v1.82.2 (deb) did not require removing the GPUCache. upgrading v1.82.2 (deb) to v1.82.3 (deb) using apt did not require removing the GPUCache. hope it helps
I'm not using the snap any more. I use the package provided directly by Microsoft from
Encountered this problem on Fedora 39, probably after upgrading my vscode rpm which is currently on version 1.82.3. Problem disappeared after running .
Not with VSCode specifically: but when updating to electron v28 alpha, had this issue. Also solved with (or just deleting the entire Electron dir within ).
Also ran into this, thanks for this workaround, it worked.
I also ran into the issue in VSCodium (which is a special build script for this source code) after an upgrade to 1.83.1 on Debian Trixie and XFCE 4.18. The worked like a charm (which is the equivalent folder on Debian for VSCodium). I did find that I only ran into the issue on my RX 550 (Lexa) and not my Radeon RX 580 (Polaris); I found that the bug disappeared when running the program with appended to it to run it on the latter graphics card.
This has happened a second time in 1.83.1.
Got it again on fedora using the rpm on a system, where I already dropped the cache once Version 1.83.1
Just installed an update with no vscode update but had a mesa update. VSCode broke again. I assume this is going to happen every time a mesa update is installed (I'm assuming because of what others are stating, could be something other than mesa but seems to be the biggest suspect).
Getting it after every mesa update. But may be "GPUCache" need some harder refresh or detection of brockage?
This issue has been fixed upstream via . It might take a while before it trickles downstream though, since it needs to be picked up by Electron first before it can go into VSCode. I did attempt cherry-picking the commit and generating a local build and it seemed to fix the issue.
The commit is fairly trivial and can probably be safely backported to all supported Electron trees. This is a very widespread issue, affecting virtually every Electron app running on Linux. It would be great to get the fix as widely disseminated as possible considering how slow the app ecosystem is to update versions. Is there a linked Electron issue for this? Do we need to create one if not or does the Electron project accept drive-by backport PRs?
I haven't found any linked Electron issues yet. Based on , since the patch is temporary, has been committed upstream, and will eventually be removed, I think the Electron folks will accept the patch. However, do take note that the commit has dependencies on previous commits. On my working local build, I have these 3 commits cherry-picked in chronological order: Therefore, if anyone is going to bring this up to the Electron team, all 3 patches would need to be merged. Add the patch files to the and append the filenames of said patch files to the . Depending on the Electron build version, there might also be some merge conflicts. Based on my experience, those conflicts should be resolvable, but I did not test all of the older Electron major version release branches. For each branch, we would need to double-check if the 2 dependency commits are already included in their respective Chromium version or not.
Thank you for the backporting work to Electron versions 25-28 over the past few days. Downstream applications should now be able to pick those fixes up. Once VSCode picks up the fix, we should be able to close this issue.
<!-- 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!
I'll verify when the next release reaches me on openSUSE.
by chance, were you able to verify the fix for the issue yet?
the time period hasn't been quite long enough to be certain. This usually occurs on an update or after approximately two months. However, VSCode did update recently, and this didn't occur (not that it was guaranteed). Consequently, if upstream has fixed the issue, and we're using the patched version, because it hasn't appeared yet, I'll keep this completed until it occurs (and we can reasonably consider this complete).
Considering the issue as verified on 1.85.x. 1.86.0 will go out in around a week. Feel free to comment on this issue thread if the issue comes up again after that.

{ "name": "code-oss-dev", "version": "1.85.0", <del> "distro": "cbc81496e34eafbc771b8f008e6a742d755968c9", </del> <ins> "distro": "210db50a0928d4857ed3d511ddb5612b947e0fef", </ins> "author": { "name": "Microsoft Corporation" },


Question:
Workaround This is an issue in Chromium itself. For now there are the following two workarounds: ### <blockQuote</blockQuote1. ### <blockQuote</blockQuote## Bug <!-- 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. -- <!-- 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. --1. ### VS Code Version Per: affected version is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.82.0-insider Commit | Date | 2023-08-11T17:10:45.392Z Electron | 25.4.0 ElectronBuildId | Chromium | 114.0.5735.248 | 18.15.0 V8 | 11.4.183.27-electron.0 OS | Linux x64 6.4.9-1-default </blockQuoteHowever, per: that , that is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.81.1 Commit | Date | 2023-08-09T22:18:39.991Z Electron | 22.3.18 ElectronBuildId | Chromium | 108.0.5359.215 | 16.17.1 V8 | 10.8.168.25-electron.0 OS | Linux x64 6.4.9-1-default snap ### OS Version <blockQuote</blockQuote</details## Steps to Reproduce 1. The GUI is invisible: the menubar continues to operate correctly.
82 updated to Electron 25 and doesn't work on older OS.
I'm using cpe:/o:opensuse:tumbleweed:, which updated 2600 packages yesterday (which I have installed) yet this problem remains. Nobody in their right mind would consider that to be old. Additionally, I am using which means that no independent part of the OS should be considered old. This is the most bleeding edge system for miles. Regardless, should I perhaps open a linked issue at
Oh, sorry, I thought it's an old OS issue. Before reporting in the electron repo, what is Help Toggle Developer Tools bringing up? Have you tried to do a clean reinstall of VSCode Insider? Perhaps it was just a bad build. Or, alternatively, you could try to download the latest Insider installer and install over your existing broken version (which I assume it's 3-4 days older than what you'd get right now) - that should effectively update it.
No problem. Thanks. Apologies for being curt. ! ! Appears that it's reproducible.
Very strange, indeed. I'm out of ideas. Would be interesting to be able to test with a previous Insider version, but for that you would need to have the old package and disable automatic updates. Electron was updated from 22 to 25 on August 8, so the last version with Electron 22 is the Insider from August 7, which is also the last version that I've tested and still working on Windows 7. Anything after that doesn't start anymore on Win 7. I'm not sure whether the Electron update on August 8 is causing your issue, though...
does the log file explain anything? To me, it seemed a little too verbose to be of much use. I can try other methods to get relevant diagnostic data if you are able to instruct me.
I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [(48)] (checkLinkStatus): Program link or binary loading failed with no info log. [(81)] Skia shader compilation error Found these: So it's definitely something related to the new Chromium included in Electron 25 and these issues seem relatively recent. The first link recommends to disable hardware acceleration, you could try searching how to do that from command line in the new Insider. Unfortunately, I don't have the time to dig deeper right now.
per , do you know whether VSCode contains a directory? I haven't been able to locate it.
remediates the problem. Because indeed this issue is dependent upon , before this update is rolled out, there needs to be remediating measures (or the update needs to be temporarily halted) lest it break a great many peoples' installations.
Can you please take a look at this? It's Chromium/Electron 25 related, so I immediately thought of you. Please see the response just above for a possible solution. Thanks!
Thanks for investigating the issue, given there are workarounds in place this is not necessarily a release blocker. I will wait for chromium to address this issue and backport the fix to Electron 25.
could a patch at least be to the affected releases to delete the relevant directory? Surely users shall be affected otherwise? I doubt we can expect them to diagnose a known issue if the solution is so simple.
We don't want to delete the GPUCache for all users and the affected scenario described in is not possible to detect from the application layer. I think the best I can do is to add this issue to the release notes and document the workarounds for visibility.
Why?
It will have impact on startup performance, for now I would wait to see the impact of this issue across our users and decide on a fix forward. The upstream issue has also been open for a while now, signifying its low impact.
Just happened again. !
This is mentioned in the 1.82 release notes I guess the issue remains in 1.83-insiders, haven't tried it yet.
It appears weird to me that solely VSCode appears to be affected by this (on my system) because Discord has been very happily updating frequently, and obviously has its own Electron-provided directory. !
Related on Stack Overflow: Related on Reddit: ,
Got this installed via fedora yesterday This wasted quiet some time on my end, as I first went searching for changes to fedora itself and finding this issue on vscode wasn't trivial.
Leaving this here for future me, as I now have that problem on a different PC
This also happens for other Electron based programs like Element and also chromium and firefox. see
I'd disagree, . It doesn't read like pragmatism - more like "didn't want to do a good fix". Startup time after the workaround felt normal. Super aggravating that this wasn't resolved with a one-time installation task to clear the GPU cache. Hard to know the aggregate cost incurred by people encountering this issue, but "not small" is probably an underestimation. Linked-issue count wouldn't be a good proxy for that metric, in that product-support's practice as shown in seems to be linking to the known-issue buried in the release notes, not to this issue. Sorry for the flames, but there you have it. When one's coding environment gets fsck'd, it's no fun, and erodes trust. Please consider.
I, for one, find great enjoyment in my coding environments.
This issue has reemerged with the latest version 1.82.3 for Ubuntu 20.04.1: Removing after the upgrade still works to get vscode running
It occurs for me almost every update of the package. It's ridiculous.
Same.
As mentioned before, this is caused by the new update in VSCode I have personally reverted to until this issue is properly solved
I was under the impression from the chromium bug that this is one time change and not required for every startup. I see that you are using snap version of VSCode, can you check if you are required to delete the cache for every start using the instead ?
I must rectify my comment: with the snap of version v1.82.1, it was required to clear the cache every startup, with v1.82.2 I don't remember having to do it, while with v1.82.3 it was needed only once on upgrade. I will edit my previous comment to fix it.
We had a runtime version bump between to , which seems like a trigger in the snap case. Can you setup deb package, we will have release this week. It would be good to confirm if updating requires to clear the cache in the deb package as well.
For what it's worth, I haven't encountered it on the rpm again
I've tried the following: removing v1.82.3 (snap) and installing v1.82.3 (deb) did require clearing the cache. removing v1.82.3 (deb) and installing v1.82.2 (deb) did not require removing the GPUCache. upgrading v1.82.2 (deb) to v1.82.3 (deb) using apt did not require removing the GPUCache. hope it helps
I'm not using the snap any more. I use the package provided directly by Microsoft from
Encountered this problem on Fedora 39, probably after upgrading my vscode rpm which is currently on version 1.82.3. Problem disappeared after running .
Not with VSCode specifically: but when updating to electron v28 alpha, had this issue. Also solved with (or just deleting the entire Electron dir within ).
Also ran into this, thanks for this workaround, it worked.
I also ran into the issue in VSCodium (which is a special build script for this source code) after an upgrade to 1.83.1 on Debian Trixie and XFCE 4.18. The worked like a charm (which is the equivalent folder on Debian for VSCodium). I did find that I only ran into the issue on my RX 550 (Lexa) and not my Radeon RX 580 (Polaris); I found that the bug disappeared when running the program with appended to it to run it on the latter graphics card.
This has happened a second time in 1.83.1.
Got it again on fedora using the rpm on a system, where I already dropped the cache once Version 1.83.1
Just installed an update with no vscode update but had a mesa update. VSCode broke again. I assume this is going to happen every time a mesa update is installed (I'm assuming because of what others are stating, could be something other than mesa but seems to be the biggest suspect).
Getting it after every mesa update. But may be "GPUCache" need some harder refresh or detection of brockage?
This issue has been fixed upstream via . It might take a while before it trickles downstream though, since it needs to be picked up by Electron first before it can go into VSCode. I did attempt cherry-picking the commit and generating a local build and it seemed to fix the issue.
The commit is fairly trivial and can probably be safely backported to all supported Electron trees. This is a very widespread issue, affecting virtually every Electron app running on Linux. It would be great to get the fix as widely disseminated as possible considering how slow the app ecosystem is to update versions. Is there a linked Electron issue for this? Do we need to create one if not or does the Electron project accept drive-by backport PRs?
I haven't found any linked Electron issues yet. Based on , since the patch is temporary, has been committed upstream, and will eventually be removed, I think the Electron folks will accept the patch. However, do take note that the commit has dependencies on previous commits. On my working local build, I have these 3 commits cherry-picked in chronological order: Therefore, if anyone is going to bring this up to the Electron team, all 3 patches would need to be merged. Add the patch files to the and append the filenames of said patch files to the . Depending on the Electron build version, there might also be some merge conflicts. Based on my experience, those conflicts should be resolvable, but I did not test all of the older Electron major version release branches. For each branch, we would need to double-check if the 2 dependency commits are already included in their respective Chromium version or not.
Thank you for the backporting work to Electron versions 25-28 over the past few days. Downstream applications should now be able to pick those fixes up. Once VSCode picks up the fix, we should be able to close this issue.
<!-- 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!
I'll verify when the next release reaches me on openSUSE.
by chance, were you able to verify the fix for the issue yet?
the time period hasn't been quite long enough to be certain. This usually occurs on an update or after approximately two months. However, VSCode did update recently, and this didn't occur (not that it was guaranteed). Consequently, if upstream has fixed the issue, and we're using the patched version, because it hasn't appeared yet, I'll keep this completed until it occurs (and we can reasonably consider this complete).
Considering the issue as verified on 1.85.x. 1.86.0 will go out in around a week. Feel free to comment on this issue thread if the issue comes up again after that.

"cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "25.9.2", </del> <ins> "electron": "25.9.4", </ins> "eslint": "8.36.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^46.5.0",


Question:
Workaround This is an issue in Chromium itself. For now there are the following two workarounds: ### <blockQuote</blockQuote1. ### <blockQuote</blockQuote## Bug <!-- 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. -- <!-- 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. --1. ### VS Code Version Per: affected version is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.82.0-insider Commit | Date | 2023-08-11T17:10:45.392Z Electron | 25.4.0 ElectronBuildId | Chromium | 114.0.5735.248 | 18.15.0 V8 | 11.4.183.27-electron.0 OS | Linux x64 6.4.9-1-default </blockQuoteHowever, per: that , that is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.81.1 Commit | Date | 2023-08-09T22:18:39.991Z Electron | 22.3.18 ElectronBuildId | Chromium | 108.0.5359.215 | 16.17.1 V8 | 10.8.168.25-electron.0 OS | Linux x64 6.4.9-1-default snap ### OS Version <blockQuote</blockQuote</details## Steps to Reproduce 1. The GUI is invisible: the menubar continues to operate correctly.
82 updated to Electron 25 and doesn't work on older OS.
I'm using cpe:/o:opensuse:tumbleweed:, which updated 2600 packages yesterday (which I have installed) yet this problem remains. Nobody in their right mind would consider that to be old. Additionally, I am using which means that no independent part of the OS should be considered old. This is the most bleeding edge system for miles. Regardless, should I perhaps open a linked issue at
Oh, sorry, I thought it's an old OS issue. Before reporting in the electron repo, what is Help Toggle Developer Tools bringing up? Have you tried to do a clean reinstall of VSCode Insider? Perhaps it was just a bad build. Or, alternatively, you could try to download the latest Insider installer and install over your existing broken version (which I assume it's 3-4 days older than what you'd get right now) - that should effectively update it.
No problem. Thanks. Apologies for being curt. ! ! Appears that it's reproducible.
Very strange, indeed. I'm out of ideas. Would be interesting to be able to test with a previous Insider version, but for that you would need to have the old package and disable automatic updates. Electron was updated from 22 to 25 on August 8, so the last version with Electron 22 is the Insider from August 7, which is also the last version that I've tested and still working on Windows 7. Anything after that doesn't start anymore on Win 7. I'm not sure whether the Electron update on August 8 is causing your issue, though...
does the log file explain anything? To me, it seemed a little too verbose to be of much use. I can try other methods to get relevant diagnostic data if you are able to instruct me.
I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [(48)] (checkLinkStatus): Program link or binary loading failed with no info log. [(81)] Skia shader compilation error Found these: So it's definitely something related to the new Chromium included in Electron 25 and these issues seem relatively recent. The first link recommends to disable hardware acceleration, you could try searching how to do that from command line in the new Insider. Unfortunately, I don't have the time to dig deeper right now.
per , do you know whether VSCode contains a directory? I haven't been able to locate it.
remediates the problem. Because indeed this issue is dependent upon , before this update is rolled out, there needs to be remediating measures (or the update needs to be temporarily halted) lest it break a great many peoples' installations.
Can you please take a look at this? It's Chromium/Electron 25 related, so I immediately thought of you. Please see the response just above for a possible solution. Thanks!
Thanks for investigating the issue, given there are workarounds in place this is not necessarily a release blocker. I will wait for chromium to address this issue and backport the fix to Electron 25.
could a patch at least be to the affected releases to delete the relevant directory? Surely users shall be affected otherwise? I doubt we can expect them to diagnose a known issue if the solution is so simple.
We don't want to delete the GPUCache for all users and the affected scenario described in is not possible to detect from the application layer. I think the best I can do is to add this issue to the release notes and document the workarounds for visibility.
Why?
It will have impact on startup performance, for now I would wait to see the impact of this issue across our users and decide on a fix forward. The upstream issue has also been open for a while now, signifying its low impact.
Just happened again. !
This is mentioned in the 1.82 release notes I guess the issue remains in 1.83-insiders, haven't tried it yet.
It appears weird to me that solely VSCode appears to be affected by this (on my system) because Discord has been very happily updating frequently, and obviously has its own Electron-provided directory. !
Related on Stack Overflow: Related on Reddit: ,
Got this installed via fedora yesterday This wasted quiet some time on my end, as I first went searching for changes to fedora itself and finding this issue on vscode wasn't trivial.
Leaving this here for future me, as I now have that problem on a different PC
This also happens for other Electron based programs like Element and also chromium and firefox. see
I'd disagree, . It doesn't read like pragmatism - more like "didn't want to do a good fix". Startup time after the workaround felt normal. Super aggravating that this wasn't resolved with a one-time installation task to clear the GPU cache. Hard to know the aggregate cost incurred by people encountering this issue, but "not small" is probably an underestimation. Linked-issue count wouldn't be a good proxy for that metric, in that product-support's practice as shown in seems to be linking to the known-issue buried in the release notes, not to this issue. Sorry for the flames, but there you have it. When one's coding environment gets fsck'd, it's no fun, and erodes trust. Please consider.
I, for one, find great enjoyment in my coding environments.
This issue has reemerged with the latest version 1.82.3 for Ubuntu 20.04.1: Removing after the upgrade still works to get vscode running
It occurs for me almost every update of the package. It's ridiculous.
Same.
As mentioned before, this is caused by the new update in VSCode I have personally reverted to until this issue is properly solved
I was under the impression from the chromium bug that this is one time change and not required for every startup. I see that you are using snap version of VSCode, can you check if you are required to delete the cache for every start using the instead ?
I must rectify my comment: with the snap of version v1.82.1, it was required to clear the cache every startup, with v1.82.2 I don't remember having to do it, while with v1.82.3 it was needed only once on upgrade. I will edit my previous comment to fix it.
We had a runtime version bump between to , which seems like a trigger in the snap case. Can you setup deb package, we will have release this week. It would be good to confirm if updating requires to clear the cache in the deb package as well.
For what it's worth, I haven't encountered it on the rpm again
I've tried the following: removing v1.82.3 (snap) and installing v1.82.3 (deb) did require clearing the cache. removing v1.82.3 (deb) and installing v1.82.2 (deb) did not require removing the GPUCache. upgrading v1.82.2 (deb) to v1.82.3 (deb) using apt did not require removing the GPUCache. hope it helps
I'm not using the snap any more. I use the package provided directly by Microsoft from
Encountered this problem on Fedora 39, probably after upgrading my vscode rpm which is currently on version 1.82.3. Problem disappeared after running .
Not with VSCode specifically: but when updating to electron v28 alpha, had this issue. Also solved with (or just deleting the entire Electron dir within ).
Also ran into this, thanks for this workaround, it worked.
I also ran into the issue in VSCodium (which is a special build script for this source code) after an upgrade to 1.83.1 on Debian Trixie and XFCE 4.18. The worked like a charm (which is the equivalent folder on Debian for VSCodium). I did find that I only ran into the issue on my RX 550 (Lexa) and not my Radeon RX 580 (Polaris); I found that the bug disappeared when running the program with appended to it to run it on the latter graphics card.
This has happened a second time in 1.83.1.
Got it again on fedora using the rpm on a system, where I already dropped the cache once Version 1.83.1
Just installed an update with no vscode update but had a mesa update. VSCode broke again. I assume this is going to happen every time a mesa update is installed (I'm assuming because of what others are stating, could be something other than mesa but seems to be the biggest suspect).
Getting it after every mesa update. But may be "GPUCache" need some harder refresh or detection of brockage?
This issue has been fixed upstream via . It might take a while before it trickles downstream though, since it needs to be picked up by Electron first before it can go into VSCode. I did attempt cherry-picking the commit and generating a local build and it seemed to fix the issue.
The commit is fairly trivial and can probably be safely backported to all supported Electron trees. This is a very widespread issue, affecting virtually every Electron app running on Linux. It would be great to get the fix as widely disseminated as possible considering how slow the app ecosystem is to update versions. Is there a linked Electron issue for this? Do we need to create one if not or does the Electron project accept drive-by backport PRs?
I haven't found any linked Electron issues yet. Based on , since the patch is temporary, has been committed upstream, and will eventually be removed, I think the Electron folks will accept the patch. However, do take note that the commit has dependencies on previous commits. On my working local build, I have these 3 commits cherry-picked in chronological order: Therefore, if anyone is going to bring this up to the Electron team, all 3 patches would need to be merged. Add the patch files to the and append the filenames of said patch files to the . Depending on the Electron build version, there might also be some merge conflicts. Based on my experience, those conflicts should be resolvable, but I did not test all of the older Electron major version release branches. For each branch, we would need to double-check if the 2 dependency commits are already included in their respective Chromium version or not.
Thank you for the backporting work to Electron versions 25-28 over the past few days. Downstream applications should now be able to pick those fixes up. Once VSCode picks up the fix, we should be able to close this issue.
<!-- 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!
I'll verify when the next release reaches me on openSUSE.
by chance, were you able to verify the fix for the issue yet?
the time period hasn't been quite long enough to be certain. This usually occurs on an update or after approximately two months. However, VSCode did update recently, and this didn't occur (not that it was guaranteed). Consequently, if upstream has fixed the issue, and we're using the patched version, because it hasn't appeared yet, I'll keep this completed until it occurs (and we can reasonably consider this complete).
Considering the issue as verified on 1.85.x. 1.86.0 will go out in around a week. Feel free to comment on this issue thread if the issue comes up again after that.

disturl "https://nodejs.org/dist" target "18.15.0" <del> ms_build_id "234519" </del> <ins> ms_build_id "243295" </ins> runtime "node" build_from_source "true"


Question:
Workaround This is an issue in Chromium itself. For now there are the following two workarounds: ### <blockQuote</blockQuote1. ### <blockQuote</blockQuote## Bug <!-- 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. -- <!-- 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. --1. ### VS Code Version Per: affected version is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.82.0-insider Commit | Date | 2023-08-11T17:10:45.392Z Electron | 25.4.0 ElectronBuildId | Chromium | 114.0.5735.248 | 18.15.0 V8 | 11.4.183.27-electron.0 OS | Linux x64 6.4.9-1-default </blockQuoteHowever, per: that , that is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.81.1 Commit | Date | 2023-08-09T22:18:39.991Z Electron | 22.3.18 ElectronBuildId | Chromium | 108.0.5359.215 | 16.17.1 V8 | 10.8.168.25-electron.0 OS | Linux x64 6.4.9-1-default snap ### OS Version <blockQuote</blockQuote</details## Steps to Reproduce 1. The GUI is invisible: the menubar continues to operate correctly.
82 updated to Electron 25 and doesn't work on older OS.
I'm using cpe:/o:opensuse:tumbleweed:, which updated 2600 packages yesterday (which I have installed) yet this problem remains. Nobody in their right mind would consider that to be old. Additionally, I am using which means that no independent part of the OS should be considered old. This is the most bleeding edge system for miles. Regardless, should I perhaps open a linked issue at
Oh, sorry, I thought it's an old OS issue. Before reporting in the electron repo, what is Help Toggle Developer Tools bringing up? Have you tried to do a clean reinstall of VSCode Insider? Perhaps it was just a bad build. Or, alternatively, you could try to download the latest Insider installer and install over your existing broken version (which I assume it's 3-4 days older than what you'd get right now) - that should effectively update it.
No problem. Thanks. Apologies for being curt. ! ! Appears that it's reproducible.
Very strange, indeed. I'm out of ideas. Would be interesting to be able to test with a previous Insider version, but for that you would need to have the old package and disable automatic updates. Electron was updated from 22 to 25 on August 8, so the last version with Electron 22 is the Insider from August 7, which is also the last version that I've tested and still working on Windows 7. Anything after that doesn't start anymore on Win 7. I'm not sure whether the Electron update on August 8 is causing your issue, though...
does the log file explain anything? To me, it seemed a little too verbose to be of much use. I can try other methods to get relevant diagnostic data if you are able to instruct me.
I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [(48)] (checkLinkStatus): Program link or binary loading failed with no info log. [(81)] Skia shader compilation error Found these: So it's definitely something related to the new Chromium included in Electron 25 and these issues seem relatively recent. The first link recommends to disable hardware acceleration, you could try searching how to do that from command line in the new Insider. Unfortunately, I don't have the time to dig deeper right now.
per , do you know whether VSCode contains a directory? I haven't been able to locate it.
remediates the problem. Because indeed this issue is dependent upon , before this update is rolled out, there needs to be remediating measures (or the update needs to be temporarily halted) lest it break a great many peoples' installations.
Can you please take a look at this? It's Chromium/Electron 25 related, so I immediately thought of you. Please see the response just above for a possible solution. Thanks!
Thanks for investigating the issue, given there are workarounds in place this is not necessarily a release blocker. I will wait for chromium to address this issue and backport the fix to Electron 25.
could a patch at least be to the affected releases to delete the relevant directory? Surely users shall be affected otherwise? I doubt we can expect them to diagnose a known issue if the solution is so simple.
We don't want to delete the GPUCache for all users and the affected scenario described in is not possible to detect from the application layer. I think the best I can do is to add this issue to the release notes and document the workarounds for visibility.
Why?
It will have impact on startup performance, for now I would wait to see the impact of this issue across our users and decide on a fix forward. The upstream issue has also been open for a while now, signifying its low impact.
Just happened again. !
This is mentioned in the 1.82 release notes I guess the issue remains in 1.83-insiders, haven't tried it yet.
It appears weird to me that solely VSCode appears to be affected by this (on my system) because Discord has been very happily updating frequently, and obviously has its own Electron-provided directory. !
Related on Stack Overflow: Related on Reddit: ,
Got this installed via fedora yesterday This wasted quiet some time on my end, as I first went searching for changes to fedora itself and finding this issue on vscode wasn't trivial.
Leaving this here for future me, as I now have that problem on a different PC
This also happens for other Electron based programs like Element and also chromium and firefox. see
I'd disagree, . It doesn't read like pragmatism - more like "didn't want to do a good fix". Startup time after the workaround felt normal. Super aggravating that this wasn't resolved with a one-time installation task to clear the GPU cache. Hard to know the aggregate cost incurred by people encountering this issue, but "not small" is probably an underestimation. Linked-issue count wouldn't be a good proxy for that metric, in that product-support's practice as shown in seems to be linking to the known-issue buried in the release notes, not to this issue. Sorry for the flames, but there you have it. When one's coding environment gets fsck'd, it's no fun, and erodes trust. Please consider.
I, for one, find great enjoyment in my coding environments.
This issue has reemerged with the latest version 1.82.3 for Ubuntu 20.04.1: Removing after the upgrade still works to get vscode running
It occurs for me almost every update of the package. It's ridiculous.
Same.
As mentioned before, this is caused by the new update in VSCode I have personally reverted to until this issue is properly solved
I was under the impression from the chromium bug that this is one time change and not required for every startup. I see that you are using snap version of VSCode, can you check if you are required to delete the cache for every start using the instead ?
I must rectify my comment: with the snap of version v1.82.1, it was required to clear the cache every startup, with v1.82.2 I don't remember having to do it, while with v1.82.3 it was needed only once on upgrade. I will edit my previous comment to fix it.
We had a runtime version bump between to , which seems like a trigger in the snap case. Can you setup deb package, we will have release this week. It would be good to confirm if updating requires to clear the cache in the deb package as well.
For what it's worth, I haven't encountered it on the rpm again
I've tried the following: removing v1.82.3 (snap) and installing v1.82.3 (deb) did require clearing the cache. removing v1.82.3 (deb) and installing v1.82.2 (deb) did not require removing the GPUCache. upgrading v1.82.2 (deb) to v1.82.3 (deb) using apt did not require removing the GPUCache. hope it helps
I'm not using the snap any more. I use the package provided directly by Microsoft from
Encountered this problem on Fedora 39, probably after upgrading my vscode rpm which is currently on version 1.82.3. Problem disappeared after running .
Not with VSCode specifically: but when updating to electron v28 alpha, had this issue. Also solved with (or just deleting the entire Electron dir within ).
Also ran into this, thanks for this workaround, it worked.
I also ran into the issue in VSCodium (which is a special build script for this source code) after an upgrade to 1.83.1 on Debian Trixie and XFCE 4.18. The worked like a charm (which is the equivalent folder on Debian for VSCodium). I did find that I only ran into the issue on my RX 550 (Lexa) and not my Radeon RX 580 (Polaris); I found that the bug disappeared when running the program with appended to it to run it on the latter graphics card.
This has happened a second time in 1.83.1.
Got it again on fedora using the rpm on a system, where I already dropped the cache once Version 1.83.1
Just installed an update with no vscode update but had a mesa update. VSCode broke again. I assume this is going to happen every time a mesa update is installed (I'm assuming because of what others are stating, could be something other than mesa but seems to be the biggest suspect).
Getting it after every mesa update. But may be "GPUCache" need some harder refresh or detection of brockage?
This issue has been fixed upstream via . It might take a while before it trickles downstream though, since it needs to be picked up by Electron first before it can go into VSCode. I did attempt cherry-picking the commit and generating a local build and it seemed to fix the issue.
The commit is fairly trivial and can probably be safely backported to all supported Electron trees. This is a very widespread issue, affecting virtually every Electron app running on Linux. It would be great to get the fix as widely disseminated as possible considering how slow the app ecosystem is to update versions. Is there a linked Electron issue for this? Do we need to create one if not or does the Electron project accept drive-by backport PRs?
I haven't found any linked Electron issues yet. Based on , since the patch is temporary, has been committed upstream, and will eventually be removed, I think the Electron folks will accept the patch. However, do take note that the commit has dependencies on previous commits. On my working local build, I have these 3 commits cherry-picked in chronological order: Therefore, if anyone is going to bring this up to the Electron team, all 3 patches would need to be merged. Add the patch files to the and append the filenames of said patch files to the . Depending on the Electron build version, there might also be some merge conflicts. Based on my experience, those conflicts should be resolvable, but I did not test all of the older Electron major version release branches. For each branch, we would need to double-check if the 2 dependency commits are already included in their respective Chromium version or not.
Thank you for the backporting work to Electron versions 25-28 over the past few days. Downstream applications should now be able to pick those fixes up. Once VSCode picks up the fix, we should be able to close this issue.
<!-- 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!
I'll verify when the next release reaches me on openSUSE.
by chance, were you able to verify the fix for the issue yet?
the time period hasn't been quite long enough to be certain. This usually occurs on an update or after approximately two months. However, VSCode did update recently, and this didn't occur (not that it was guaranteed). Consequently, if upstream has fixed the issue, and we're using the patched version, because it hasn't appeared yet, I'll keep this completed until it occurs (and we can reasonably consider this complete).
Considering the issue as verified on 1.85.x. 1.86.0 will go out in around a week. Feel free to comment on this issue thread if the issue comes up again after that.

resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.9.2: version "25.9.2" resolved "https://registry.yarnpkg.com/electron/-/electron-25.9.2.tgz#12be98fbcff485c94ff99df21e0727797a45364a" integrity sha512-hVBN5rsrL99BKNHvzMeYy2PkAmewuIobu4U3o3EzVz4MDoLmMfW4yTH5GZ4RbJrpokoEky5IzGtRR/ggPzL6Fw== </del> <ins> electron@25.9.4: version "25.9.4" resolved "https://registry.yarnpkg.com/electron/-/electron-25.9.4.tgz#1935b6fbfd8ad920719a4136d867021496703884" integrity sha512-5pDU8a7o7ZIPTZHAqjflGMq764Favdsc271KXrAT3oWvFTHs5Ve9+IOt5EUVPrwvC2qRWKpCIEM47WzwkTlENQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"


Question: Type: <bBug</bPort forwarding over ssh is not working using vscode-insiders. It is working using vscode. How to replicate: some http server on the remote the port to be forwarded and select http as a protocol opening in browser / doing a curl from your local machine the request is stuck pending VS Code version: Code - Insiders 1.82.0-insider (, 2023-08-21T05:32:43.957Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 6.1.38-59.109.amzn2023.x8664 <details<summarySystem Info</summary </details<details<summaryExtensions (54)</summaryExtensionVersion ------ Handlebars0.4.1 vsc-python-indent1.18.0 dotenv1.0.1 remote-containers0.305.0 remote-ssh0.105.1 remote-ssh-edit0.86.0 remote-wsl0.81.0 vscode-remote-extensionpack0.24.0 remote-explorer0.4.1 remote-server1.4.2 material-icon-theme4.29.0 indent-one-space1.0.0 vscode-todo-highlight1.0.5 nugetpackagemanagergui2.0.6 Handlebars0.4.1 vue-peek1.0.2 vscode-markdownlint0.51.0 vscode-eslint2.4.2 gitlens2023.8.1905 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-jest-runner0.4.66 copilot1.104.347 copilot-chat0.7. vscode-github-actions0.26.1 todo-tree0.0.226 terraform2.27. vscode-test-explorer2.21.1 vscode-nuget-package-manager1.1.6 roslynator4.4.0 vsc-python-indent1.18.0 vscode-python-test-adapter0.7.1 dotenv1.0.1 vscode-scss0.10.0 vscode-docker1.26.0 csharp2.0.376 vscode-dotnet-runtime1.7.0 black-formatter2023.5. flake82023.7. isort2023.11. python2023.15. vscode-pylance2023.8.31 test-adapter-converter0.1.8 indent-rainbow8.3.1 material-icon-theme4.29.0 prisma5.1.0 vscode-scss-formatter3.0.0 indent-one-space1.0.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-conventional-commits1.25.0 volar1.8.8 vscode-typescript-vue-plugin1.8.8 vscode-todo-highlight1.0.5 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details

import { IRemoteSocketFactoryService } from 'vs/platform/remote/common/remoteSocketFactoryService'; import { ISignService } from 'vs/platform/sign/common/sign'; import { AbstractTunnelService, ISharedTunnelsService, ITunnelProvider, ITunnelService, RemoteTunnel, TunnelPrivacyId, isAllInterfaces, isLocalhost, isPortPrivileged, isTunnelProvider } from 'vs/platform/tunnel/common/tunnel'; <ins> import { VSBuffer } from 'vs/base/common/buffer'; </ins> async function createRemoteTunnel(options: IConnectionOptions, defaultTunnelHost: string, tunnelRemoteHost: string, tunnelRemotePort: number, tunnelLocalPort?: number): Promise<RemoteTunnel> { let readyTunnel: NodeRemoteTunnel | undefined;


Question: Type: <bBug</bPort forwarding over ssh is not working using vscode-insiders. It is working using vscode. How to replicate: some http server on the remote the port to be forwarded and select http as a protocol opening in browser / doing a curl from your local machine the request is stuck pending VS Code version: Code - Insiders 1.82.0-insider (, 2023-08-21T05:32:43.957Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 6.1.38-59.109.amzn2023.x8664 <details<summarySystem Info</summary </details<details<summaryExtensions (54)</summaryExtensionVersion ------ Handlebars0.4.1 vsc-python-indent1.18.0 dotenv1.0.1 remote-containers0.305.0 remote-ssh0.105.1 remote-ssh-edit0.86.0 remote-wsl0.81.0 vscode-remote-extensionpack0.24.0 remote-explorer0.4.1 remote-server1.4.2 material-icon-theme4.29.0 indent-one-space1.0.0 vscode-todo-highlight1.0.5 nugetpackagemanagergui2.0.6 Handlebars0.4.1 vue-peek1.0.2 vscode-markdownlint0.51.0 vscode-eslint2.4.2 gitlens2023.8.1905 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-jest-runner0.4.66 copilot1.104.347 copilot-chat0.7. vscode-github-actions0.26.1 todo-tree0.0.226 terraform2.27. vscode-test-explorer2.21.1 vscode-nuget-package-manager1.1.6 roslynator4.4.0 vsc-python-indent1.18.0 vscode-python-test-adapter0.7.1 dotenv1.0.1 vscode-scss0.10.0 vscode-docker1.26.0 csharp2.0.376 vscode-dotnet-runtime1.7.0 black-formatter2023.5. flake82023.7. isort2023.11. python2023.15. vscode-pylance2023.8.31 test-adapter-converter0.1.8 indent-rainbow8.3.1 material-icon-theme4.29.0 prisma5.1.0 vscode-scss-formatter3.0.0 indent-one-space1.0.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-conventional-commits1.25.0 volar1.8.8 vscode-typescript-vue-plugin1.8.8 vscode-todo-highlight1.0.5 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details

remoteSocket.onClose(() => localSocket.destroy()); remoteSocket.onEnd(() => localSocket.end()); remoteSocket.onData(d => localSocket.write(d.buffer)); <ins> localSocket.on('data', d => remoteSocket.write(VSBuffer.wrap(d))); </ins> localSocket.resume(); }


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This would replace . Proposal: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ declare module 'vscode' { // export enum RelatedInformationType { SymbolInformation = 1, CommandInformation = 2, SearchInformation = 3, SettingInformation = 4 } interface RelatedInformationBaseResult { type: RelatedInformationType; weight: number; } // TODO: Symbols and Search export interface CommandInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.CommandInformation; command: string; } export interface SettingInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.SettingInformation; setting: string; } export type RelatedInformationResult = CommandInformationResult | SettingInformationResult; export interface RelatedInformationProvider { provideRelatedInformation(query: string, token: CancellationToken): ProviderResult<RelatedInformationResult[]; } export interface EmbeddingVectorProvider { provideEmbeddingVector(strings: string[], token: CancellationToken): ProviderResult<number[][]; } export namespace ai { export function getRelatedInformation(query: string, types: RelatedInformationType[], token: CancellationToken): Thenable<RelatedInformationResult[]; export function registerRelatedInformationProvider(type: RelatedInformationType, provider: RelatedInformationProvider): Disposable; export function registerEmbeddingVectorProvider(model: string, provider: EmbeddingVectorProvider): Disposable; } }

import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { InstantiationType, registerSingleton } from 'vs/platform/instantiation/common/extensions'; import { ISemanticSimilarityService } from 'vs/workbench/services/semanticSimilarity/common/semanticSimilarityService'; <ins> import { IAiRelatedInformationService, RelatedInformationType, SettingInformationResult } from 'vs/workbench/services/aiRelatedInformation/common/aiRelatedInformation'; </ins> export interface IEndpointDetails { urlBase?: string;


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This would replace . Proposal: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ declare module 'vscode' { // export enum RelatedInformationType { SymbolInformation = 1, CommandInformation = 2, SearchInformation = 3, SettingInformation = 4 } interface RelatedInformationBaseResult { type: RelatedInformationType; weight: number; } // TODO: Symbols and Search export interface CommandInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.CommandInformation; command: string; } export interface SettingInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.SettingInformation; setting: string; } export type RelatedInformationResult = CommandInformationResult | SettingInformationResult; export interface RelatedInformationProvider { provideRelatedInformation(query: string, token: CancellationToken): ProviderResult<RelatedInformationResult[]; } export interface EmbeddingVectorProvider { provideEmbeddingVector(strings: string[], token: CancellationToken): ProviderResult<number[][]; } export namespace ai { export function getRelatedInformation(query: string, types: RelatedInformationType[], token: CancellationToken): Thenable<RelatedInformationResult[]; export function registerRelatedInformationProvider(type: RelatedInformationType, provider: RelatedInformationProvider): Disposable; export function registerEmbeddingVectorProvider(model: string, provider: EmbeddingVectorProvider): Disposable; } }

private settingsRecord: Record<string, ISetting> = {}; private currentPreferencesModel: ISettingsEditorModel | undefined; <del> constructor(private readonly semanticSimilarityService: ISemanticSimilarityService) { } </del> <ins> constructor( private readonly aiRelatedInformationService: IAiRelatedInformationService, private readonly semanticSimilarityService: ISemanticSimilarityService ) { } </ins> updateModel(preferencesModel: ISettingsEditorModel) { if (preferencesModel === this.currentPreferencesModel) {


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This would replace . Proposal: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ declare module 'vscode' { // export enum RelatedInformationType { SymbolInformation = 1, CommandInformation = 2, SearchInformation = 3, SettingInformation = 4 } interface RelatedInformationBaseResult { type: RelatedInformationType; weight: number; } // TODO: Symbols and Search export interface CommandInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.CommandInformation; command: string; } export interface SettingInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.SettingInformation; setting: string; } export type RelatedInformationResult = CommandInformationResult | SettingInformationResult; export interface RelatedInformationProvider { provideRelatedInformation(query: string, token: CancellationToken): ProviderResult<RelatedInformationResult[]; } export interface EmbeddingVectorProvider { provideEmbeddingVector(strings: string[], token: CancellationToken): ProviderResult<number[][]; } export namespace ai { export function getRelatedInformation(query: string, types: RelatedInformationType[], token: CancellationToken): Thenable<RelatedInformationResult[]; export function registerRelatedInformationProvider(type: RelatedInformationType, provider: RelatedInformationProvider): Disposable; export function registerEmbeddingVectorProvider(model: string, provider: EmbeddingVectorProvider): Disposable; } }

this.settingKeys = []; this.settingsRecord = {}; <del> if (!this.semanticSimilarityService.isEnabled() || !this.currentPreferencesModel) { </del> <ins> if ( !this.currentPreferencesModel || (!this.semanticSimilarityService.isEnabled() && !this.aiRelatedInformationService.isEnabled()) ) { </ins> return; }


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This would replace . Proposal: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ declare module 'vscode' { // export enum RelatedInformationType { SymbolInformation = 1, CommandInformation = 2, SearchInformation = 3, SettingInformation = 4 } interface RelatedInformationBaseResult { type: RelatedInformationType; weight: number; } // TODO: Symbols and Search export interface CommandInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.CommandInformation; command: string; } export interface SettingInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.SettingInformation; setting: string; } export type RelatedInformationResult = CommandInformationResult | SettingInformationResult; export interface RelatedInformationProvider { provideRelatedInformation(query: string, token: CancellationToken): ProviderResult<RelatedInformationResult[]; } export interface EmbeddingVectorProvider { provideEmbeddingVector(strings: string[], token: CancellationToken): ProviderResult<number[][]; } export namespace ai { export function getRelatedInformation(query: string, types: RelatedInformationType[], token: CancellationToken): Thenable<RelatedInformationResult[]; export function registerRelatedInformationProvider(type: RelatedInformationType, provider: RelatedInformationProvider): Disposable; export function registerEmbeddingVectorProvider(model: string, provider: EmbeddingVectorProvider): Disposable; } }

constructor( @ISemanticSimilarityService private readonly semanticSimilarityService: ISemanticSimilarityService, <ins> @IAiRelatedInformationService private readonly aiRelatedInformationService: IAiRelatedInformationService </ins> ) { <del> this._keysProvider = new RemoteSearchKeysProvider(semanticSimilarityService); </del> <ins> this._keysProvider = new RemoteSearchKeysProvider(aiRelatedInformationService, semanticSimilarityService); </ins> } setFilter(filter: string) {


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This would replace . Proposal: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ declare module 'vscode' { // export enum RelatedInformationType { SymbolInformation = 1, CommandInformation = 2, SearchInformation = 3, SettingInformation = 4 } interface RelatedInformationBaseResult { type: RelatedInformationType; weight: number; } // TODO: Symbols and Search export interface CommandInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.CommandInformation; command: string; } export interface SettingInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.SettingInformation; setting: string; } export type RelatedInformationResult = CommandInformationResult | SettingInformationResult; export interface RelatedInformationProvider { provideRelatedInformation(query: string, token: CancellationToken): ProviderResult<RelatedInformationResult[]; } export interface EmbeddingVectorProvider { provideEmbeddingVector(strings: string[], token: CancellationToken): ProviderResult<number[][]; } export namespace ai { export function getRelatedInformation(query: string, types: RelatedInformationType[], token: CancellationToken): Thenable<RelatedInformationResult[]; export function registerRelatedInformationProvider(type: RelatedInformationType, provider: RelatedInformationProvider): Disposable; export function registerEmbeddingVectorProvider(model: string, provider: EmbeddingVectorProvider): Disposable; } }

} async searchModel(preferencesModel: ISettingsEditorModel, token?: CancellationToken | undefined): Promise<ISearchResult | null> { <del> if (!this.semanticSimilarityService.isEnabled() || !this._filter) { </del> <ins> if ( !this._filter || (!this.semanticSimilarityService.isEnabled() && !this.aiRelatedInformationService.isEnabled())) { </ins> return null; } this._keysProvider.updateModel(preferencesModel); <ins> const filterMatches = this.aiRelatedInformationService.isEnabled() ? await this.getAiRelatedInformationItems(token) : this.semanticSimilarityService.isEnabled() ? await this.getSemanticSimilarityItems(token) : []; return { filterMatches }; } // TODO: Remove this when all semantic similarity providers are migrated to aiRelatedInformationService private async getSemanticSimilarityItems(token?: CancellationToken | undefined) { </ins> const settingKeys = this._keysProvider.getSettingKeys(); const settingsRecord = this._keysProvider.getSettingsRecord();


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This would replace . Proposal: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ declare module 'vscode' { // export enum RelatedInformationType { SymbolInformation = 1, CommandInformation = 2, SearchInformation = 3, SettingInformation = 4 } interface RelatedInformationBaseResult { type: RelatedInformationType; weight: number; } // TODO: Symbols and Search export interface CommandInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.CommandInformation; command: string; } export interface SettingInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.SettingInformation; setting: string; } export type RelatedInformationResult = CommandInformationResult | SettingInformationResult; export interface RelatedInformationProvider { provideRelatedInformation(query: string, token: CancellationToken): ProviderResult<RelatedInformationResult[]; } export interface EmbeddingVectorProvider { provideEmbeddingVector(strings: string[], token: CancellationToken): ProviderResult<number[][]; } export namespace ai { export function getRelatedInformation(query: string, types: RelatedInformationType[], token: CancellationToken): Thenable<RelatedInformationResult[]; export function registerRelatedInformationProvider(type: RelatedInformationType, provider: RelatedInformationProvider): Disposable; export function registerEmbeddingVectorProvider(model: string, provider: EmbeddingVectorProvider): Disposable; } }

}); numOfSmartPicks++; } <del> return { filterMatches }; </del> <ins> return filterMatches; } private async getAiRelatedInformationItems(token?: CancellationToken | undefined) { const settingsRecord = this._keysProvider.getSettingsRecord(); const filterMatches: ISettingMatch[] = []; const relatedInformation = await this.aiRelatedInformationService.getRelatedInformation(this._filter, [RelatedInformationType.SettingInformation], token ?? CancellationToken.None) as SettingInformationResult[]; relatedInformation.sort((a, b) => b.weight - a.weight); for (const info of relatedInformation) { if (info.weight < RemoteSearchProvider.SEMANTIC_SIMILARITY_THRESHOLD || filterMatches.length === RemoteSearchProvider.SEMANTIC_SIMILARITY_MAX_PICKS) { break; } const pick = info.setting; filterMatches.push({ setting: settingsRecord[pick], matches: [settingsRecord[pick].range], matchType: SettingMatchType.RemoteMatch, score: info.weight }); } return filterMatches; </ins> } }


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This would replace . Proposal: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ declare module 'vscode' { // export enum RelatedInformationType { SymbolInformation = 1, CommandInformation = 2, SearchInformation = 3, SettingInformation = 4 } interface RelatedInformationBaseResult { type: RelatedInformationType; weight: number; } // TODO: Symbols and Search export interface CommandInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.CommandInformation; command: string; } export interface SettingInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.SettingInformation; setting: string; } export type RelatedInformationResult = CommandInformationResult | SettingInformationResult; export interface RelatedInformationProvider { provideRelatedInformation(query: string, token: CancellationToken): ProviderResult<RelatedInformationResult[]; } export interface EmbeddingVectorProvider { provideEmbeddingVector(strings: string[], token: CancellationToken): ProviderResult<number[][]; } export namespace ai { export function getRelatedInformation(query: string, types: RelatedInformationType[], token: CancellationToken): Thenable<RelatedInformationResult[]; export function registerRelatedInformationProvider(type: RelatedInformationType, provider: RelatedInformationProvider): Disposable; export function registerEmbeddingVectorProvider(model: string, provider: EmbeddingVectorProvider): Disposable; } }

command: string; } <ins> export interface SettingInformationResult extends RelatedInformationResult { type: RelatedInformationType.SettingInformation; setting: string; } </ins> export interface IAiRelatedInformationService { readonly _serviceBrand: undefined;


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This would replace . Proposal: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ declare module 'vscode' { // export enum RelatedInformationType { SymbolInformation = 1, CommandInformation = 2, SearchInformation = 3, SettingInformation = 4 } interface RelatedInformationBaseResult { type: RelatedInformationType; weight: number; } // TODO: Symbols and Search export interface CommandInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.CommandInformation; command: string; } export interface SettingInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.SettingInformation; setting: string; } export type RelatedInformationResult = CommandInformationResult | SettingInformationResult; export interface RelatedInformationProvider { provideRelatedInformation(query: string, token: CancellationToken): ProviderResult<RelatedInformationResult[]; } export interface EmbeddingVectorProvider { provideEmbeddingVector(strings: string[], token: CancellationToken): ProviderResult<number[][]; } export namespace ai { export function getRelatedInformation(query: string, types: RelatedInformationType[], token: CancellationToken): Thenable<RelatedInformationResult[]; export function registerRelatedInformationProvider(type: RelatedInformationType, provider: RelatedInformationProvider): Disposable; export function registerEmbeddingVectorProvider(model: string, provider: EmbeddingVectorProvider): Disposable; } }

import { StopWatch } from 'vs/base/common/stopwatch'; import { ILogService } from 'vs/platform/log/common/log'; <ins> /** * @deprecated Use `IAiRelatedInformationService` instead. */ </ins> export const ISemanticSimilarityService = createDecorator<ISemanticSimilarityService>('ISemanticSimilarityService'); <ins> /** * @deprecated Use `IAiRelatedInformationService` instead. */ </ins> export interface ISemanticSimilarityService { readonly _serviceBrand: undefined;


Question:
Repro: a perf profile a ~100mb TypeScript file (duplicate the contents of a large TS file to make this) perf profile ! It doesn't end up working properly anyway: !
After delete and undo: !

private _readConfiguration() { const options = this._editor.getOption(EditorOption.stickyScroll); if (options.enabled === false) { this._editor.removeOverlayWidget(this._stickyScrollWidget); this._sessionStore.clear();


Question:
Repro: a perf profile a ~100mb TypeScript file (duplicate the contents of a large TS file to make this) perf profile ! It doesn't end up working properly anyway: !
After delete and undo: !

} private _renderStickyScroll() { <del> if (!(this._editor.hasModel())) { </del> <ins> const model = this._editor.getModel(); if (!model || model.isTooLargeForTokenization()) { this._stickyScrollWidget.setState(undefined); </ins> return; } <del> const model = this._editor.getModel(); </del> const stickyLineVersion = this._stickyLineCandidateProvider.getVersionId(); if (stickyLineVersion === undefined || stickyLineVersion === model.getVersionId()) { this._widgetState = this.findScrollWidgetState();


Question:
Repro: a perf profile a ~100mb TypeScript file (duplicate the contents of a large TS file to make this) perf profile ! It doesn't end up working properly anyway: !
After delete and undo: !

return this._lineNumbers; } <del> setState(state: StickyScrollWidgetState): void { dom.clearNode(this._lineNumbersDomNode); dom.clearNode(this._linesDomNode); </del> <ins> setState(state: StickyScrollWidgetState | undefined): void { this._clearStickyWidget(); if (!state) { return; } </ins> this._stickyLines = []; const editorLineHeight = this._editor.getOption(EditorOption.lineHeight); const futureWidgetHeight = state.startLineNumbers.length * editorLineHeight + state.lastLineRelativePosition;


Question:
Repro: a perf profile a ~100mb TypeScript file (duplicate the contents of a large TS file to make this) perf profile ! It doesn't end up working properly anyway: !
After delete and undo: !

this._rootDomNode.style.width = `${layoutInfo.width - layoutInfo.minimap.minimapCanvasOuterWidth - layoutInfo.verticalScrollbarWidth}px`; } <ins> private _clearStickyWidget() { dom.clearNode(this._lineNumbersDomNode); dom.clearNode(this._linesDomNode); this._rootDomNode.style.display = 'none'; } </ins> private _renderRootNode(): void { if (!this._editor._getViewModel()) {


Question:
Repro: a perf profile a ~100mb TypeScript file (duplicate the contents of a large TS file to make this) perf profile ! It doesn't end up working properly anyway: !
After delete and undo: !

const editorLineHeight = this._editor.getOption(EditorOption.lineHeight); const widgetHeight: number = this._lineNumbers.length * editorLineHeight + this._lastLineRelativePosition; <del> this._rootDomNode.style.display = widgetHeight > 0 ? 'block' : 'none'; </del> <ins> if (widgetHeight === 0) { this._clearStickyWidget(); return; } this._rootDomNode.style.display = 'block'; </ins> this._lineNumbersDomNode.style.height = `${widgetHeight}px`; this._linesDomNodeScrollable.style.height = `${widgetHeight}px`; this._rootDomNode.style.height = `${widgetHeight}px`;


Question:
Repro: a perf profile a ~100mb TypeScript file (duplicate the contents of a large TS file to make this) perf profile ! It doesn't end up working properly anyway: !
After delete and undo: !

'Variable 0 will be a file name.' ] }, <del> "{0}: tokenization, wrapping and folding have been turned off for this large file in order to reduce memory usage and avoid freezing or crashing.", </del> <ins> "{0}: tokenization, wrapping, folding and sticky scroll have been turned off for this large file in order to reduce memory usage and avoid freezing or crashing.", </ins> path.basename(model.uri.path) );


Question:
<!-- 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. --- VS Code Version: 1.81.1 OS Version: server 2022 Steps to Reproduce: is a system install. Users login using redirected appdata folders launch code with appdata redirected to a unc path or can launch 'code --user-data-dir servershare$code' error Unable to write program user data , code trying to write to c:share$ Users do not have access to write to c: grant full control to root of C: and launch code a new folder is created c:share$ file created c:share$codeUserglobalStorage is created and code launches does not use the unc path while all other files are written to servershare$code fine with version 1.79.2
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.81.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
based on the above steps looks like the sqlite database is not using the unc path, passing the issue to you.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
Same issue. installed 1.82.0-insider build. Still creates the in the wrong location.
excellent finding! I think this is a regression from partitioning state per profile. Specifically: When using , UNC paths only work for scheme but now I think we have as scheme. I am not sure when we made that flip.
I think this is spreading to a lot more places, the code is very old and was always assuming scheme to be used, which will not work anymore if a UNC path is used: I think we will have to make a pass over usage and find those that potentially use a non-file scheme...
I think I start to understand the issue better, it seems quite specific to global storage only, the other in the seem to be mainly of scheme. I believe this started with moving out of the environment service and into the profile service:
The change to scheme started happening from this change - - I started using this scheme for all user data to adopt atomic write. Since I had reverted atomic write for user data in this commit - - I can revert to use file scheme for user data on main. But going forward, I will bring back user data scheme and probably we should our file service and uri identitiy utilities instead of using fspath and path join.
but there is a point where our file service is no longer in charge: when we hand of a to SQLite3 module, we really have to give it a proper path that is a UNC path if the user picked a UNC location. So just using will not help here, we need to find a way that is not breaking UNC paths in all places where we need it.
Thats right, I also observed that we browsing the storage code. May be we should convert this back to file scheme before using in those places?
yes, doing seems right to me, even though ugly. Curious: with your custom file system provider on , are you converting back to a URI and then handing the off to the disk file system provider? Or do you convert one level above on the level of the file service? Asking, because I wonder if there is already a bug in your provider where we potentially loose UNC paths.
Thinking a bit more about this, I wonder if should statically allow us to register a scheme to behave like a scheme. Because, we do take an existing well defined of scheme and turn that into . This in turn means, every client that deals with such a would need to ensure that the scheme is converted back to before using the . That seems fragile. If we could tell to treat like a scheme, maybe the change would be easier and less fragile?
IMO this is as ugly as using on URI, because it can cause issues anytime. Even if you know the scheme of the URI converting to file scheme is always safe. Here is the conversion logic: This is handled in the FSP of vscode-userdata. I just change the scheme and pass it to the native FSP.

import { memoize } from 'vs/base/common/decorators'; import { join } from 'vs/base/common/path'; import { isLinux } from 'vs/base/common/platform'; <ins> import { URI } from 'vs/base/common/uri'; </ins> import { createStaticIPCHandle } from 'vs/base/parts/ipc/node/ipc.net'; import { IEnvironmentService, INativeEnvironmentService } from 'vs/platform/environment/common/environment'; import { NativeEnvironmentService } from 'vs/platform/environment/node/environmentService';


Question:
<!-- 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. --- VS Code Version: 1.81.1 OS Version: server 2022 Steps to Reproduce: is a system install. Users login using redirected appdata folders launch code with appdata redirected to a unc path or can launch 'code --user-data-dir servershare$code' error Unable to write program user data , code trying to write to c:share$ Users do not have access to write to c: grant full control to root of C: and launch code a new folder is created c:share$ file created c:share$codeUserglobalStorage is created and code launches does not use the unc path while all other files are written to servershare$code fine with version 1.79.2
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.81.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
based on the above steps looks like the sqlite database is not using the unc path, passing the issue to you.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
Same issue. installed 1.82.0-insider build. Still creates the in the wrong location.
excellent finding! I think this is a regression from partitioning state per profile. Specifically: When using , UNC paths only work for scheme but now I think we have as scheme. I am not sure when we made that flip.
I think this is spreading to a lot more places, the code is very old and was always assuming scheme to be used, which will not work anymore if a UNC path is used: I think we will have to make a pass over usage and find those that potentially use a non-file scheme...
I think I start to understand the issue better, it seems quite specific to global storage only, the other in the seem to be mainly of scheme. I believe this started with moving out of the environment service and into the profile service:
The change to scheme started happening from this change - - I started using this scheme for all user data to adopt atomic write. Since I had reverted atomic write for user data in this commit - - I can revert to use file scheme for user data on main. But going forward, I will bring back user data scheme and probably we should our file service and uri identitiy utilities instead of using fspath and path join.
but there is a point where our file service is no longer in charge: when we hand of a to SQLite3 module, we really have to give it a proper path that is a UNC path if the user picked a UNC location. So just using will not help here, we need to find a way that is not breaking UNC paths in all places where we need it.
Thats right, I also observed that we browsing the storage code. May be we should convert this back to file scheme before using in those places?
yes, doing seems right to me, even though ugly. Curious: with your custom file system provider on , are you converting back to a URI and then handing the off to the disk file system provider? Or do you convert one level above on the level of the file service? Asking, because I wonder if there is already a bug in your provider where we potentially loose UNC paths.
Thinking a bit more about this, I wonder if should statically allow us to register a scheme to behave like a scheme. Because, we do take an existing well defined of scheme and turn that into . This in turn means, every client that deals with such a would need to ensure that the scheme is converted back to before using the . That seems fragile. If we could tell to treat like a scheme, maybe the change would be easier and less fragile?
IMO this is as ugly as using on URI, because it can cause issues anytime. Even if you know the scheme of the URI converting to file scheme is always safe. Here is the conversion logic: This is handled in the FSP of vscode-userdata. I just change the scheme and pass it to the native FSP.

@memoize get useCodeCache(): boolean { return !!this.codeCachePath; } <ins> @memoize override get userRoamingDataHome(): URI { return this.appSettingsHome; } </ins> unsetSnapExportedVariables() { if (!isLinux) { return;


Question: It should be just "Copy Output", the "to Clipboard" is obvious? This then aligns with other copy actions across the product Testing

"title": "%cleanInvalidImageAttachment.title%" }, { <del> "command": "notebook.cellOutput.copyToClipboard", "title": "%copyOutputToClipboard.title%" </del> <ins> "command": "notebook.cellOutput.copy", "title": "%copyCellOutput.title%" </ins> } ], "notebooks": [


Question: It should be just "Copy Output", the "to Clipboard" is obvious? This then aligns with other copy actions across the product Testing

], "webview/context": [ { <del> "command": "notebook.cellOutput.copyToClipboard", </del> <ins> "command": "notebook.cellOutput.copy", </ins> "when": "webviewId == 'notebook.output' && webviewSection == 'image'" } ]


Question: It should be just "Copy Output", the "to Clipboard" is obvious? This then aligns with other copy actions across the product Testing

"newUntitledIpynb.shortTitle": "Jupyter Notebook", "openIpynbInNotebookEditor.title": "Open IPYNB File In Notebook Editor", "cleanInvalidImageAttachment.title": "Clean Invalid Image Attachment Reference", <del> "copyOutputToClipboard.title": "Copy Output to Clipboard", </del> <ins> "copyCellOutput.title": "Copy Output", </ins> "markdownAttachmentRenderer.displayName": { "message": "Markdown-It ipynb Cell Attachment renderer", "comment": [


Question: It should be just "Copy Output", the "to Clipboard" is obvious? This then aligns with other copy actions across the product Testing

import { CellKind } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { CodeCellViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/codeCellViewModel'; <del> export const COPY_OUTPUT_COMMAND_ID = 'notebook.cellOutput.copyToClipboard'; </del> <ins> export const COPY_OUTPUT_COMMAND_ID = 'notebook.cellOutput.copy'; </ins> registerAction2(class CopyCellOutputAction extends Action2 { constructor() { super({ id: COPY_OUTPUT_COMMAND_ID, <del> title: localize('notebookActions.copyOutput', "Copy Output to Clipboard"), </del> <ins> title: localize('notebookActions.copyOutput', "Copy Output"), </ins> menu: { id: MenuId.NotebookOutputToolbar, when: NOTEBOOK_CELL_HAS_OUTPUTS


Question: Testing open execute a cell that shows issues select copy output no output is copied I'd except that this "just works", at least for its text/markdown output representation

'application/x.notebook.stream', 'application/vnd.code.notebook.stderr', 'application/x.notebook.stderr', <del> 'text/plain' </del> <ins> 'text/plain', 'text/markdown', 'application/json' </ins> ];


Question:
Going through the error logs showed the error below . No steps but it is rooted at this line
verification - Perform a few actions in a notebook, add cells, run cells, close/reopen the tab, run more cells Open the dev tools and ensure the error is not in the console

this._loadState(); this._register(this._storageService.onWillSaveState(() => this._saveState())); this._register(this._storageService.onDidChangeValue(StorageScope.WORKSPACE, NotebookKernelHistoryService.STORAGE_KEY, this._register(new DisposableStore()))(() => { <del> this._restoreState(); </del> <ins> this._loadState(); </ins> })); }


Question:
Going through the error logs showed the error below . No steps but it is rooted at this line
verification - Perform a few actions in a notebook, add cells, run cells, close/reopen the tab, run more cells Open the dev tools and ensure the error is not in the console

} } <del> private _restoreState(): void { const serialized = this._storageService.get(NotebookKernelHistoryService.STORAGE_KEY, StorageScope.WORKSPACE); if (serialized) { try { for (const [viewType, kernels] of JSON.parse(serialized)) { const linkedMap = this._mostRecentKernelsMap[viewType] ?? new LinkedMap<string, string>(); for (const entry of kernels.entries) { linkedMap.set(entry, entry, Touch.AsOld); } this._mostRecentKernelsMap[viewType] = linkedMap; } } catch (e) { console.error('Deserialize notebook kernel history failed', e); } } } </del> private _loadState(): void { const serialized = this._storageService.get(NotebookKernelHistoryService.STORAGE_KEY, StorageScope.WORKSPACE); if (serialized) {


Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

import { workspace, window, languages, commands, ExtensionContext, extensions, Uri, ColorInformation, Diagnostic, StatusBarAlignment, TextEditor, TextDocument, FormattingOptions, CancellationToken, FoldingRange, <del> ProviderResult, TextEdit, Range, Position, Disposable, CompletionItem, CompletionList, CompletionContext, Hover, MarkdownString, FoldingContext, DocumentSymbol, SymbolInformation, l10n, TextEditorOptions </del> <ins> ProviderResult, TextEdit, Range, Position, Disposable, CompletionItem, CompletionList, CompletionContext, Hover, MarkdownString, FoldingContext, DocumentSymbol, SymbolInformation, l10n </ins> } from 'vscode'; import { LanguageClientOptions, RequestType, NotificationType, FormattingOptions as LSPFormattingOptions,


Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

export namespace SettingIds { export const enableFormatter = 'json.format.enable'; export const enableKeepLines = 'json.format.keepLines'; <del> export const enableSortOnSave = 'json.sortOnSave.enable'; </del> export const enableValidation = 'json.validate.enable'; export const enableSchemaDownload = 'json.schemaDownload.enable'; export const maxItemsComputed = 'json.maxItemsComputed';


Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

window.showInformationMessage(l10n.t('JSON schema cache cleared.')); })); <del> toDispose.push(workspace.onWillSaveTextDocument(event => { const sortOnSave = workspace.getConfiguration().get<boolean>(SettingIds.enableSortOnSave); const document = event.document; if (sortOnSave && (document.languageId === 'json' || document.languageId === 'jsonc')) { const documentOptions = getOptionsForDocument(document); const textEditsPromise = getSortTextEdits(document, documentOptions?.tabSize, documentOptions?.insertSpaces); event.waitUntil(textEditsPromise); } })); </del> toDispose.push(commands.registerCommand('json.sort', async () => {


Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

function isSchemaResolveError(d: Diagnostic) { return d.code === /* SchemaResolveError */ 0x300; } <del> function getOptionsForDocument(document: TextDocument): TextEditorOptions | undefined { for (const editor of window.visibleTextEditors) { if (editor.document.uri.toString() === document.uri.toString()) { return editor.options; } } return; } </del>


Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

"default": false, "description": "%json.format.keepLines.desc%" }, <del> "json.sortOnSave.enable": { "type": "boolean", "scope": "window", "default": false, "description": "%json.sortOnSave.enable.desc%" }, </del> "json.trace.server": { "type": "string", "scope": "window",


Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

"json.schemas.schema.desc": "The schema definition for the given URL. The schema only needs to be provided to avoid accesses to the schema URL.", "json.format.enable.desc": "Enable/disable default JSON formatter", "json.format.keepLines.desc" : "Keep all existing new lines when formatting.", <del> "json.sortOnSave.enable.desc": "Enable/disable default sorting on save", </del> "json.validate.enable.desc": "Enable/disable JSON validation.", "json.tracing.desc": "Traces the communication between VS Code and the JSON language server.", "json.colorDecorators.enable.desc": "Enables or disables color decorators",