GH-8723: From now on, proxy factories do not wait for reconnect once the websocket connection was disposed

[kittaakos]

What it does

It changes the behavior of the proxy-factories when running the app in an electron environment. As logged under #8723, there is no promise rejection when the user tries to save the content of the dirty editors and the backend process is down.
With the current logic from the master, as soon as the websocket connection is disposed, all remote calls are queued up and wait until there is another, new websocket connection. This behavior can be useful in the browser environment, but not necessarily required for Electron. There is not much we can do other than handling the promise rejection and notifying the user about the fatal crash.

This PR is a noop for the browser.

If you have a better idea of how to make this customization without if (!environment.electron.is()), let me know. I want to keep the changeset as small and possible. Of course, this PR must not introduce any breaking change in downstream.

How to test

• Build the electron app with the sample,
• Start the elecrton app,
• Disable auto-save,
• Make one of the files dirty,
• Kill the backend process (you can search for Backend is up and running. [PID: number] in the logs),
• Save the editor.
• You should see the handled rejection:

Closes #8723

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[paul-marechal]

LGTM, confirmed that the issue is fixed on Windows 10.

[akosyakov]

it does not throw on purpose to avoid rejecting consequent operations

[kittaakos]

Thanks for the note. Well, we should reject it somehow. That would be the desired flow when clients want to handle errors. If the error was swallowed on purpose, that's a problem. What was the problematic use-case?

[kittaakos]

I can filter the error and rethrow only when it indicates t a connection disposed issue, but the rejection must happen, preferably always.

[akosyakov]

maybe something like:

const result = this.pendingOperation.then(() = operation());
this.pendingOperation = result.catch(e => console.error(e));
return result;

but we should also check all clients of run that they expect that now sync and save can throw and can deal with it

[kittaakos]

OK, I will check the call sites. Thanks! Eventually, I am fine with introducing a new template method, handleError, with console.log(error) default implementation in the monaco-editor-model.ts module, but best would be to have the error handling in Theia.

[JonasHelming]

@paul-marechal : Could you decide whether we want to merge this?

Stale review.

[paul-marechal]

I am not confident merging this patch after all this time. There's also unresolved comments.

I'd rather close this one for now and keep track of the issue through #10723