Open tudortimi opened 3 weeks ago
The same also happens for the extensions view:
With Internet, it loads instantly.
Reassigning to @joyceerhl based on the "Failed to fetch chat participant registry" error.
@rzhao271 I don't imagine that this has anything to do with chat participants. The problem here seems to be that we may not have the right timeouts configured for network requests, which results in our UI not appearing responsive. Reassigning to Sandeep for extensions view.
Unable to repro on Windows 11. Does the issue still occur with extensions disabled?
Yes, it does. Many of my colleagues said they didn't see this with 1.86.x or something around that version.
Is there a way to add even more verbosity to the network calls? I was curious to see what URL are being hit. I tried with --log trace
, but it didn't show anything extra.
The "Developer: Toggle Developer Tools" command opens a devtools window which allows you to view network request under the Network tab.
I see the following (copied as cURL):
curl 'https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery' \
-H 'sec-ch-ua: "Not-A.Brand";v="99", "Chromium";v="124"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.92.2 Chrome/124.0.6367.243 Electron/30.1.2 Safari/537.36' \
-H 'content-type: application/json' \
-H 'accept: application/json;api-version=3.0-preview.1' \
-H 'Referer;' \
-H 'x-market-client-id: VSCode 1.92.2' \
-H 'sec-ch-ua-platform: "Linux"' \
--data-raw '{"filters":[{"criteria":[{"filterType":7,"value":"GitHub.copilot"},{"filterType":8,"value":"Microsoft.VisualStudio.Code"},{"filterType":12,"value":"4096"}],"pageNumber":1,"pageSize":1,"sortBy":0,"sortOrder":0}],"assetTypes":[],"flags":950}'
and
curl 'https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery' \
-X 'OPTIONS' \
-H 'Accept: */*' \
-H 'Access-Control-Request-Headers: content-type,x-market-client-id' \
-H 'Access-Control-Request-Method: POST' \
-H 'Origin: vscode-file://vscode-app' \
-H 'Sec-Fetch-Mode: cors' \
-H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.92.2 Chrome/124.0.6367.243 Electron/30.1.2 Safari/537.36'
The same requests are triggered also when running without extensions.
For "Timing", this is what is shown:
I tried to click on "Explanation", but I don't get anything.
If I start the same request manually with curl
, they time out in 2m11s:
This is consistent with the "2.2 min" shown by VS Code. Is this perhaps an OS default which is different in Linux and Windows, hence the reason you don't see the problem on Windows 11?
We have the same Problem.
Yes, it does. Many of my colleagues said they didn't see this with 1.86.x or something around that version.
It first showed up at our environment with 1.92.2 (with 1.92.1, we got no problem with the settings).
Can you please file a separate issue for Extensions View and investigate them separately. If we end up having same root cause then we can mark them as duplicates. As of now, I do not think they have same root cause. Both components should be rendered irrespective of network connectivity.
A similar issue also exists for the extensions view: #227446
I did some bisecting. The last version where settings loading works properly in our environment is 1.84.0. The first version where it becomes slow is 1.84.1.
Does this issue occur when all extensions are disabled?: Yes
I use VS Code in a restricted network environment, without access to the Internet. Whenever I try to open the settings UI, it takes a very long time to load (in the order of minutes):
I tried starting with
--verbose
. I see what I believe is VS Code recognizing the command:Later on, I see the following when the settings have been populated in the GUI:
I'm guessing the
TypeError
warning is related to some kind of network timeout.I can temporarily start VS Code with Internet access (albeit for a very short period of time). If I try to open the settings UI in this case, it populates immediately. This is why I'm assuming this is somehow related to network timeouts.