fix(site): correct autostop restart prompt on the workspace schedule page - #27632
Conversation
The schedule page gated the restart-to-apply dialog on the workspace's pre-submit autostop state, so enabling autostop on a running workspace never prompted and the new deadline only applied on the next start. Key the prompt off the submitted form value instead via a small pure helper, shouldConfirmAutostopRestart, so enabling or changing autostop while running prompts, while disabling (which clears the running build's deadline server-side) does not. This also restores the original intent of #16085, which meant to skip the prompt when removing autostop but keyed off the old state.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Add Storybook play-function coverage for the autostop restart prompt and document the trigger conditions inline: enabling or changing the value while running prompts; disabling or a stopped workspace does not. Rework the prior story that asserted the pre-fix behavior of prompting when disabling autostop.
Dismissing the restart confirmation with "Apply later" navigated away to the workspace, same as confirming. Close the dialog instead so the user stays on the schedule page; the saved value still applies on the next start.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 21d7c6235e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // effect immediately, but only when all of the following hold: | ||
| // - autostop actually changed (toggled or new TTL value), | ||
| // - autostop is enabled after the change; disabling clears the | ||
| // running build's deadline server-side, so no restart is | ||
| // needed, and |
There was a problem hiding this comment.
Condense the restart-predicate comment
Keep the useful backend invariant, but remove the bullet-by-bullet walkthrough of the three conditions directly below it. This ten-line comment largely restates the if control flow and exceeds the frontend guidance to reserve comments for non-obvious constraints in one to three lines.
AGENTS.md reference: site/AGENTS.md:L15-L15
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
I think this area is pretty ambiguous, someone else can comment to this fact but this is an implementation detail that was already a problem once. I like the verbosity. YOMV.
Problem
Enabling autostop on a running workspace never showed the "restart now to apply?" dialog. The new TTL was saved, but a running build's deadline is only calculated when the build starts, so autostop silently did not take effect until a manual restart. Changing an already-enabled value did prompt, so the behavior was inconsistent.
Separately, dismissing that dialog with Apply later navigated the user away to the workspace, exactly like confirming did.
Root cause
The dialog was gated on
getAutostop(workspace).autostopEnabled, which derives fromworkspace.ttl_ms— the pre-submit state (the workspace is not refetched until after the mutation). That expression means "was autostop enabled before this change", which maps to:falsetruetrueThis guard came from #16085, which intended to skip the prompt when removing autostop (safe, because that PR also made the backend clear a running build's deadline server-side when TTL is set to null). By keying off the old state it actually skipped the prompt on add and still showed it on remove — the opposite of its intent.
Fix
values.autostopEnabled), with an inline comment documenting the trigger conditions. This fixes the reported bug and restores feat: allow removing deadline for running workspace #16085's intent:Testing
Storybook
play-function coverage onWorkspaceSchedulePagefor all cases: enable, change value, disable, enable-while-stopped, autostart-only, and Apply-later-stays-on-page (the last also assertsrestartWorkspaceis not called). A prior story that asserted the pre-fix behavior (prompting on disable) was reworked.tscandbiomeclean.Investigation notes
History of the gating condition:
if (data.autostopChanged) { ... }— prompted on every autostop change (enable included).&& getAutostop(workspace).autostopEnabled. Its description states the goal was to "not show a confirmation dialog when the change is to remove autostop", and the same PR added backend logic inputWorkspaceTTLto clear a running build's deadline when TTL is null.&& workspace.latest_build.status === "running".Because the backend already clears the deadline live on removal, no restart is needed there; the frontend only needs to prompt when autostop ends up enabled on a running workspace. The fix keys off the submitted state so all three transitions behave correctly.