[server] maintain workspace instance state

[svenefftinge]

Description

get closer to workspace instance state reflects actual state in cluster.

Related Issue(s)

Fixes #12067

How to test

Release Notes

NONE

Documentation

Werft options:

• /werft with-preview

[werft-gitpod-dev-com]

started the job as gitpod-build-sefftinge-server-improve-maintenance-12067.1 because the annotations in the pull request description changed
(with .werft/ from main)

[AlexTugarev]

/werft run

👍 started the job as gitpod-build-sefftinge-server-improve-maintenance-12067.2
(with .werft/ from main)

[AlexTugarev]

I didn't find any places where either stoppedTime or stoppingTime would be set without the status being set accordingly.

OTOH there is a handling of wsman events where the RUNNING phase is being persisted blindly

gitpod/components/ws-manager-bridge/src/bridge.ts

Line 158 in 24f7b60

instance.status.phase = "running";

That said, I'm fine this adding this check here, but it seems, it should be done before the RUNNING phase is persisted bogusly.

cc. @geropl because he reimplemented the status mapping for prebuilds, which seems to be a better pattern for the whole update cascade of states.

[AlexTugarev]

Thanks! That change to workspace starter makes great sense 🥇

I left a comment on the change to the bridge – it seems to that it reverts a bogus status update in error cases, which in itself sounds ok. Actually we need to avoid having persisted the bogus state beforehand, not least because these status updates are used as base of prebuild status updates and client notifications via messagebus. That's definitely tracking as a separate issue, and perhaps solve it like it's done for the prebuild status updates.