Hubert P

I've been doing more profiling and experimenting with replacing circe yaml parsing. But I guess for now we can stay with snakeYAML only that we will need to write encoders/decoders...

I wlll create a separate ticket for 2.3 SnakeYAML upgrade.

`Received InboundMessage with unknown payload type [1]` looks like a culprit.

In my case I'm getting a blank page as well but no errors on backend. Maybe one of the console errors explains?  

> i assume cloud.enso.org still doesn't work as it's still using GUI1? Whaaa? Well that would explain things. But I talked to @PabloBuchu yesterday and he said it is running...

I'm seeing (with trace level logs) something suspicious: ``` May 02 15:40:30 ip-172-31-0-127.eu-west-1.compute.internal enso_runtime[2573]: [TRACE] [2024-05-02T15:40:30Z] [org.enso.librarymanager.local.DefaultLocalLibraryProvider] Local library Standard.Base not found at [***/libraries]. May 02 15:40:30 ip-172-31-0-127.eu-west-1.compute.internal enso_runtime[2573]: [TRACE]...

Actually that doesn't seem to be the cause of the problem. I will need to investigate why it happens in the first place but it seems to recover from this...

Not sure how relevant that is but why is GUI reporting a wrong version in cloud? I thought it's using latest nightly? 

So I have a fix for the timeout that is being reported when using electron app and connection to the cloud. The issue is basically... weak hardware. On my machine...

~~Some progress. Now failing with~~ distilled to https://github.com/enso-org/enso/issues/9876 ``` May 07 10:17:23 ip-172-31-10-107.eu-west-1.compute.internal enso_runtime[11629]: [ERROR] [2024-05-07T10:17:23Z] [org.enso.languageserver.runtime.RuntimeConnector$Endpoint] Failed to deserialize runtime API envelope May 07 10:17:23 ip-172-31-10-107.eu-west-1.compute.internal enso_runtime[11629]: com.fasterxml.jackson.databind.exc.InvalidTypeIdException: Could...