Description
Description
The Workspace schedule (Autostart/Autostop) and dormancy features can be configured at 2 levels:
- Template-level
- Workspace-level
Prebuilt workspaces inherit these lifecycle configurations from their associated template or workspace. However, prebuilds should not actively follow these settings until they are claimed by a user (i.e., when the owner_id
transitions from the prebuilds user to a regular user). Applying lifecycle logic prematurely conflicts with prebuild-specific behaviors, such as the expiration_policy
and prebuild scheduling
mechanisms, which are designed to manage prebuilds independently of user-driven workspace lifecycle features.
Actual Behavior
- Prebuilds start behaving as if they are regular workspaces (autostarting, stopping, or becoming dormant) before they are claimed.
- Specifically, the lifecycle executor (which manages these features) may stop prebuilds based on the inherited configuration.
- However, stopped prebuilds are not counted as running by the reconciliation loop, which monitors and ensures that the number of running prebuild instances matches the desired number.
- As a result, the reconciliation loop will see fewer running prebuilds than desired and will attempt to start new prebuild instances, leading to churn, inefficiency, and instability in the prebuild system.
Expected Behavior
- Prebuilds can inherit lifecycle settings from the template or workspace.
- These settings should not be enforced or acted upon while the workspace is in the prebuild phase (owned by the prebuilds user).
- Once a prebuild is claimed (ownership changes to a regular user), the lifecycle settings should take effect.
Proposed Fix
Introduce logic to skip enforcement of Autostart, Autostop, and Dormancy in the lifecycle_executor
for workspaces owned by the prebuilds user. Enforcement should only begin once ownership is transferred to a real user.
Related with: #18658