You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the UI derives time remaining for a running workspace from its ttl. This implies that if a user turns on a workspace that is scheduled to stop 8 hours later, then adjusts their ttl to 4 hours, the UI will present that the workspace will shutdown 4 hours later.
However, the underlying model uses a deadline on the build. The deadline may be stickier than ttl - for example, updating your ttl while your workspace is live may or may not cascade to your build.
Therefore it's best that the FE does the following:
for a running workspace, compute shutdown time from build deadline
for a non-running workspace, compute shutdown time from workspace ttl
Why It Matters
We want to accurately present when a workspace will shutdown, and not have a mismatch.
The text was updated successfully, but these errors were encountered:
Overview
Right now, the UI derives time remaining for a running workspace from its ttl. This implies that if a user turns on a workspace that is scheduled to stop 8 hours later, then adjusts their ttl to 4 hours, the UI will present that the workspace will shutdown 4 hours later.
However, the underlying model uses a deadline on the build. The deadline may be stickier than ttl - for example, updating your ttl while your workspace is live may or may not cascade to your build.
Therefore it's best that the FE does the following:
Why It Matters
We want to accurately present when a workspace will shutdown, and not have a mismatch.
The text was updated successfully, but these errors were encountered: