For the latest version of monaco-editor-wrapper, and previous versions, passing an invalid LS url causes the application to become unresponsive. This can happen when the languageClientConfig.workerConfigOptions of the UserConfig contains either:
a worker setup with an invalid url: (ex. new Worker('oops.js'))
a configuration for worker with a url:
{
url: new URL('oops.js', window.location.href),
type: 'module',
name: 'some-name',
}
In either case, if the resulting UserConfig that contains this unreachable url is passed into the start method of a wrapper, the application will hang indefinitely.
const wrapper = new MonacoEditorLanguageClientWrapper();
await wrapper.start(userConfig);
// no rejection or resolution happens, effectively frozen
This issue is particularly hard to debug as a result, and once found it's often unclear why the start method isn't returning.
As a possible solution, we should make a 'best attempt' to determine that a given url (or pre-configured Worker) is valid. If not we should reject, allowing the resulting promise to finish up, and report the relevant error back to the user. The question remains at what stage within the wrapper to perform this sanity check, but if we can detect this case that would help others to resolve this issue quickly.
For the latest version of monaco-editor-wrapper, and previous versions, passing an invalid LS url causes the application to become unresponsive. This can happen when the
languageClientConfig.workerConfigOptionsof the UserConfig contains either:new Worker('oops.js'))In either case, if the resulting
UserConfigthat contains this unreachable url is passed into the start method of a wrapper, the application will hang indefinitely.This issue is particularly hard to debug as a result, and once found it's often unclear why the
startmethod isn't returning.As a possible solution, we should make a 'best attempt' to determine that a given url (or pre-configured Worker) is valid. If not we should reject, allowing the resulting promise to finish up, and report the relevant error back to the user. The question remains at what stage within the wrapper to perform this sanity check, but if we can detect this case that would help others to resolve this issue quickly.