When a workspace is idled for inactivity user is redirected to Che dashboard

[benoitf]

Is your enhancement related to a problem? Please describe

Let say I'm accessing an endpoint of a workspace at

https://che-eclipse-che.apps.my-cluster.com/workspace<tons-of-digits>/<endpoint-name>/8080

if my workspace is stopped, I will get like a basic 503 error (or another http error)

Describe the solution you'd like

I would like to have a page allowing to be redirected to the dashboard to restart my workspace if the workspace is down

Describe alternatives you've considered

Anything that may be more user friendly for the user if he refresh the editor page on a stopped workspace

Release Notes Text

When a workspace is stopped after an inactivity now the users are redirected to the Dashboard. Previously a 503 error was displayed.

[dkwon17]

Hi, I would like to help investigate this issue

[dkwon17]

Does anyone know how this was implemented for che-server based workspaces?

I don't know how it was implemented before, but an idea I have for this issue is to use the Errors middleware https://doc.traefik.io/traefik/middlewares/http/errorpages/ to redirect requests to the dashboard when there is a 503/504 error code

[sparkoo]

@dkwon17 I would guess that behavior with che-workspaces was similar to what's reported here. The traefik's errors middleware looks promising.

[dkwon17]

Thank you @sparkoo , I'll take a deeper look

[benoitf]

@dkwon17 it was not implemented for che-server workspaces.

Che-Server workspaces were displayed through an iframe of the dashboard.
So URL opened/displayed in the browser was the dashboard URL which was always responding/there.

Now, as we're connected directly to the IDE route without being included in an Iframe this is why it needs to be handled on the routing side.

[dkwon17]

So far, I was able to get the middleware to sometimes work. I found that it works consistently if I delete the workspace service (screenshot) created in the user namespace after the workspace stops:

This seems to be because the request to the service sometimes hangs for a few minutes if there are no pods, which causes traefik to close the request, preventing the errors middleware from firing:

If the workspace service doesn't exist when the workspace stops, then the request to the non-existent service quickly results in an error, which the errors middleware can handle.

[dkwon17]

Hi @amisevsk , when a DW stops, would having the DWO delete the workspace service ({workspaceID}-service) during the DW reconciliation be reasonable?

EDIT:
Maybe we don't need to delete the service. I noticed that if I set my own connection timeout for the service: https://doc.traefik.io/traefik/routing/services/#forwardingtimeouts, then the Errors middleware will kick in after the timeout.

In other words, if I set the timeout to 5s, when an idled workspace is refreshed, we will try to establish a connection to the workspace service for 5s. If we cannot, then the Errors middlware redirects the request to the dashboard.

[amisevsk]

Deleting the service would be controlled by the Che Operator, as it hosts the routing controller for the che routingClass. Che Operator would need to delete resources when it reconciles a DevWorkspaceRouting with the controller.devfile.io/devworkspace-started: "false" annotation.

Currently, DWO will clean up workspace resources (including the DevWorkspaceRouting) if it has the configuration setting config.workspace.cleanupOnStop set to true, and this may become a default behavior in the future.

[dkwon17]

I have two WIP implementations, at the moment I'm leaning towards implementation 2 since I think it is a bit simpler:

Implementation 1: Change traefik routes when devworkspace is stopped: eclipse-che/che-operator#1386

• Redirects user to dashboard immediately since the traefik routes themselves are changed to direct requests to the dashboard
• Need to add new functionality in the DWO repo to facilitate routing changes on devworkspace stop: (PR: feat: add WorkspaceStopped method to RoutingSolver devfile/devworkspace-operator#839)

Implementation 2: Use errors middleware: Branch

• Redirects user to dashboard after 4 seconds (this value can be changed, see here)
• Need to edit the dashboard. Dashboard doesn't load because of this check: https://github.com/eclipse-che/che-dashboard/blob/073c0be5c0d14187fabb5109fecdca78a07f13d3/packages/dashboard-frontend/src/preload/index.ts#L14-L16
• No need to edit traefik config when workspace stops/starts

I suspect it might be easier to redirect to a dashboard error page with implementation 2, because the Errors middleware has a dedicated query section that should accept URL query parameters if needed.

[ibuziuk]

I also lean towards the middleware errors approach without changing the traefik config.
We should be careful with the Dashboard change though, I recall it might be related to https://github.com/eclipse-che/che-operator/pull/1360/files
@olexii4 @akurinnoy wdyt?

[ibuziuk]

@dkwon17 all the PRs have been merged, can the issue be closed?

[dkwon17]

@ibuziuk I would say so. For context, refreshing the editor page of a stopped workspace now results in this page from the dashboard:

[max-cx]

sync'd to Red Hat Jira https://issues.redhat.com/browse/CRW-3181