An unexpected error occurred for a not secure connection at using Open Folder command

[azatsarynnyy]

Describe the bug

After loading Che-Code, I get the error message:

An unexpected error occurred that requires a reload of this page.
The workbench failed to connect to the server (Error: WebSocket close with status code 1006)

UPDATE: please see #21392 (comment)

Che version

next (development version)

Steps to reproduce

Just start a workspace with Che-Code editor.

Expected behavior

Che-Code must be loaded with no error popping up.

Runtime

minikube

Screenshots

Installation method

chectl/next

Environment

Linux

Eclipse Che Logs

No response

Additional context

Logs of the Che-Code container:

total 28
drwxrwxrwx 6 root root 4096 May 11 15:44 .
drwxr-xr-x 1 root root 4096 May 11 17:54 ..
drwxr-xr-x 2 1234 root 4096 May 11 15:42 bin
drwxr-xr-x 7 1234 root 4096 May 11 15:42 checode-linux-libc
drwxr-xr-x 7 1234 root 4096 May 11 15:42 checode-linux-musl
-rwxr-xr-x 1 1234 root 1083 May 11 17:54 entrypoint-volume.sh
drwx------ 4 1234 root 4096 May 11 15:44 remote
time="2022-05-11T17:54:55Z" level=info msg="Default 'info' log level is applied"
time="2022-05-11T17:54:55Z" level=info msg="Exec containers configuration:"
time="2022-05-11T17:54:55Z" level=info msg="==> Debug level info"
time="2022-05-11T17:54:55Z" level=info msg="==> Application url 0.0.0.0:3333"
time="2022-05-11T17:54:55Z" level=info msg="==> Absolute path to folder with static resources "
time="2022-05-11T17:54:55Z" level=info msg="==> Use bearer token: false"
time="2022-05-11T17:54:55Z" level=info msg="==> Pod selector: controller.devfile.io/devworkspace_id=workspaceb2504da404354163"
[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.
[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:	export GIN_MODE=release
 - using code:	gin.SetMode(gin.ReleaseMode)
[GIN-debug] GET    /connect                  --> main.main.func2 (3 handlers)
[GIN-debug] GET    /attach/:id               --> main.main.func3 (3 handlers)
[GIN-debug] POST   /exec/config              --> main.main.func4 (3 handlers)
[GIN-debug] POST   /exec/init                --> main.main.func5 (3 handlers)
[GIN-debug] POST   /activity/tick            --> main.main.func6 (3 handlers)
[GIN-debug] GET    /healthz                  --> main.main.func7 (3 handlers)
⇩ Registered RPCRoutes:
Json-rpc MachineExec Routes:
✓ create
✓ check
✓ resize
✓ listContainers
[GIN-debug] Listening and serving HTTP on 0.0.0.0:3333
Server bound to 127.0.0.1:3100 (IPv4)
Extension host agent listening on 3100
Web UI available at http://localhost:3100/
[17:55:01] Extension host agent started.
[GIN] 2022/05/11 - 17:55:01 | 200 |     209.739µs |       127.0.0.1 | GET      /connect
[17:56:16] [127.0.0.1][f7cfd4bd][ManagementConnection] New connection established.
[17:56:17] RemoteTerminalChannel: unsupported command/$getTerminalLayoutInfo
[17:56:18] RemoteTerminalChannel: unsupported command/$reduceConnectionGraceTime

[azatsarynnyy]

It seems to be reproduced randomly. After waiting for a few minutes and reloading the page, there is no error message on Che-Code start.
As there's a workaround, I'm lowering the severity from blocker to P1.

[azatsarynnyy]

I can't reproduce it anymore. So, closing the issue.

[azatsarynnyy]

I still receive feedback from the internal users (at Red Hat) that the issue is reproduced sporadically. There're no specific steps to reproduce. Often, there is also a Dashboard banner informing about the WebSocket issues:

[azatsarynnyy]

We've discussed that internally with @olexii4 today. It was proposed to investigate how VS Code handles WebSocket errors in order to reconnect. Possibly, VS Code doesn't handle some type of errors. If so, we could enhance VS Code built-in mechanism for WebSocket status checking.

[azatsarynnyy]

Downstream issue: https://issues.redhat.com/browse/CRW-3412

[azatsarynnyy]

In most cases, this problem is reproduced when Che is deployed on a local cluster: CRC, minikube.

[RomanNikitenko]

I was able to reproduce the problem only for not secure connections (a certificate was not provided or is invalid):

Another condition to reproduce the issue - Open Folder command usage.

So, two things are required to face with issue:

• valid certificate is not provided
• use Open Folder command

The issue was detected at starting IDE step for not secure connections as starting Che-Code had 2 steps:

• loading the IDE
• open a project using Open Folder command by API.

See Che-Code loading twice at workspace startup for more details.

The issue is not actual for starting IDE after merging che-incubator/che-code#131 as Open Folder command is not used anymore to open a project. But a user still might face the issue:

• for not secure connection
• close a current project and use Open Folder command to open another project/folder

[RomanNikitenko]

I've changed the title of the issue, please see details in my previous comment.

[azatsarynnyy]

Thank you @RomanNikitenko for the great investigation!
Considering that, after fixing #21400, the steps to reproduce this issue are not typical for the Che user (closing the current VS Code Workspace),
I believe it makes little sense to continue investing in a fix for this issue.
I'm decreasing the issue's priority to P2. We can come back to it once there will be a real use case when the issue is relevant.

[l0rd]

@azatsarynnyy I agree that we can reduce the priority. I would even close it and eventually re-open if we reproduce it.

[azatsarynnyy]

okay, I'm closing it as not relevant anymore for the Che use cases.