- Notifications
You must be signed in to change notification settings - Fork1k
fix: disallow lifecycle endpoints for prebuilt workspaces#19264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
fix: disallow lifecycle endpoints for prebuilt workspaces#19264
Conversation
| // Prebuild lifecycle is managed by the reconciliation loop, with scheduling behavior | ||
| // defined per preset at the template level, not per workspace. | ||
| ifworkspace.IsPrebuild() { | ||
| httpapi.Write(ctx,rw,http.StatusConflict, codersdk.Response{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
409 Conflict based on discussion:#19252 (comment)
## DescriptionThis PR ensures that prebuilt workspaces are properly excluded from thelifecycle executor and treated as a separate class of workspaces, fullymanaged by the prebuild reconciliation loop.It introduces two lifecycle guarantees:* When a prebuilt workspace is created (i.e., when the workspace buildcompletes), all lifecycle-related fields are unset, ensuring theworkspace does not participate in TTL, autostop, autostart, dormancy, orauto-deletion logic.* When a prebuilt workspace is claimed, it transitions into a regularuser workspace. At this point, all lifecycle fields are correctlypopulated according to template-level configurations, allowing theworkspace to be managed by the lifecycle executor as expected.## Changes* Prebuilt workspaces now have all lifecycle-relevant fields unsetduring creation* When a prebuild is claimed:* Lifecycle fields are set based on template and workspace levelconfigurations. This ensures a clean transition into the standardworkspace lifecycle flow.* Updated lifecycle-related SQL update queries to explicitly excludeprebuilt workspaces.## Relates Related issue:#18898To reduce the scope of this PR and make the review process moremanageable, the original implementation has been split into thefollowing focused PRs:*#19259*#19263*#19264*#19265These PRs should be considered in conjunction with this one tounderstand the complete set of lifecycle separation changes for prebuiltworkspaces.
| } | ||
| // Use injected Clock to allow time mocking in tests | ||
| now:=api.Clock.Now() |
ssncferreiraAug 13, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
If I understand correctly, all timestamps in the database are stored in UTC.
Do we need to explicitly set this to UTC? I see it being done in other places, for instance, in settingnextStartAt:https://github.com/coder/coder/blob/main/coderd/workspaces.go#L574
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Generally it's recommended to usedbtime.Time as this also rounds to the microsecond which is the smallest unit of precision supported by Postgres.
But if you're just using it as an initial reference point I'd say it should be OK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Yes, the pattern I have been following is using theClock.Now() on the application layer, anddtime.Time for database operations.
| } | ||
| // Use injected Clock to allow time mocking in tests | ||
| now:=api.Clock.Now() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Generally it's recommended to usedbtime.Time as this also rounds to the microsecond which is the smallest unit of precision supported by Postgres.
But if you're just using it as an initial reference point I'd say it should be OK.
734299d intomainUh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Description
This PR updates the API to prevent lifecycle configuration endpoints from being used on prebuilt workspaces. Since prebuilds are managed by the reconciliation loop and do not participate in the regular workspace lifecycle, they must not support per-workspace overrides for fields like deadline, TTL, autostart, or dormancy.
Attempting to use these endpoints on a prebuilt workspace will now return a clear validation error (
409 Conflict) with an appropriate explanation. This prevents accidental misconfiguration and preserves the lifecycle separation between prebuilds and regular workspaces.Changes
The following endpoints now return an error if the target workspace is a prebuild:
PUT /workspaces/{workspace}/extendPUT /workspaces/{workspace}/ttlPUT /workspaces/{workspace}/autostartPUT /workspaces/{workspace}/dormantUpdate endpoints logic to use the API clock in order to allow time mocking in tests.
Related with: