[db] Add statusVersion to prebuilds to track status version

[easyCZ]

Description

Related Issue(s)

• [bridge] Ensure we do not override "failed" instance states (affects prebuilds!) #8596
• Use WorkspaceStatus.status_version to ignore old status updates #9107

How to test

1. Preview works
2. New prebuilds can start
3. Column statusVersion appears in the DB

Release Notes

NONE

Documentation

/hold
/uncc

[easyCZ]

Not entirely happy that the statusVersion needs to be exposed in the protocol and sent to clients. Is there a way (without significantly changing the system) to have this data only available to internal components and continue not having it in clients?

[geropl]

continue not having it in clients?

You could :

1. introduce a sub-shape of that we use in protocol, and a more expanded shape we expose in GitpodService
2. and hand-remove this field when sending it to clients (we do this with some sensitive field of WorkspaceInstance in GitpodServerImpl)
3. but I'm not sure it warrant's the effort, now and for this single field. Let's hope make it better with the new API 😉

[easyCZ]

Thanks, that's what I was thinking as well. Unless there is a strong objection, I'll leave it as is for now.

[geropl]

@easyCZ I wonder if we could place the field into WorkspaceInstance generically, because there we'll have to have it as well. And then we have duplication. 🤔

[easyCZ]

@easyCZ I wonder if we could place the field into WorkspaceInstance generically, because there we'll have to have it as well. And then we have duplication. 🤔

I'd rather avoid inheritance for things like the DB schema and core protocol. It introduces coupling which can create unintended side-effects (especially on the DB level) when you try to break it up.

I'm happy to compose it into both, however, if you think it's needed.

[geropl]

I'd rather avoid inheritance for things like the DB schema and core protocol.

Hm, I'd rather stick to the current idea of "data deduplication" (inheritance 👻 ) even if maintain the tight coupling between both tables. If we want to split it out we have to look at it more holistically I fear.

There might be a reason for duplication, though, especially for prebuilds. But I cannot think of one ad-hoc. 🤔

[easyCZ]

From what I can see, the ORM definition of Prebuilds does not currently have any inheritance specified [file].

And neither does the protocol [file]. Where exactly do you want to add inheritance?

I'd be open to defining an interface which has a field statusVersion which we can use to type the objects but YAGNI?

[geropl]

Summary: We're going with the statusVersion field in the prebuilds tabe
Reasoning:
we want to have statusVersion the API-facing shape
we agree that WorkspaceInstance will use the same field at some point
it's unpractical to read statusVersion from prebuiold (2-join Workspace->WorkspaceInstance.statusVersion)
we're taking the slight risk of data-duplication/-races in favor of
following the current pattern for API shapes (same as internal)
following the current pattern by having all fields in the shape in the DB table
Also, statusVersion tells us something about the data quality of all fields in the table (data provenance), so might make sense to duplicate it in the first place 🙃

[geropl]

LGTM

[easyCZ]

Thanks for the review and discussion @geropl!

/unhold