Closed as not planned
Description
Is there an existing issue for this?
- I have searched the existing issues
OS/Web Information
N/A
Steps to Reproduce
- Cause the
workbench.web.main.jsbundle to take a long time to load (could try the browser's dev tools or a reverse proxy or something). - You will know you hit the bug when you see errors like
Loading "vs/base/common/uri" failedor requests to things like/static/out/vs/base/common/path.jsbecause those are individual files bundled intoworkbench.web.main.jsand are not packaged individually in production.
Expected
Should eventually load.
Actual
It seem to time out and then start trying to load dev sources instead which of course do not exist so all you get are 404s.
Workarounds
- Clear cache but this may not work if the network is consistently slow.
- Cache
workbench.web.main.jsahead of time in the browser by going to it directly (this may time out as well depending on where the timeout is happening).
Proposed fixes
- Try figuring out the source of the timeout. Is it the browser itself? The Code loader?
- Remove the timeout if it is something we control. The perfect solution would add a loading message as well.
- If it is not something we can prevent can we at least detect the failure and then show a message saying loading the workbench timed out (and the cause if that information is available) and to try again rather than fall back to dev sources?
Logs
See linked issues.
Screenshot/Video
See linked issues.
Does this issue happen in VS Code or GitHub Codespaces?
It probably reproduces in Codespaces, still need to give it a shot though.
- I cannot reproduce this in VS Code.
- I cannot reproduce this in GitHub Codespaces.
Are you accessing code-server over HTTPS?
- I am using HTTPS.
Notes
This probably is an upstream issue but it happens often enough that we might want to proactively look into it. I briefly searched for an issue upstream but did not find one; if we can reproduce with Codespaces we might want to open an issue there as well.