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