fix: during workspace bulk start/stop, skip workspaces already in target state - #27108
Merged
aqandrew merged 3 commits intoJul 9, 2026
Conversation
…et state Previously, bulk start required every selected workspace to be stopped, and bulk stop required every selected workspace to be running. Mixed selections disabled both buttons entirely. Change the disabled checks from every() to some() so the buttons are enabled when at least one workspace is eligible. Filter workspaces by status in the mutation functions so only eligible workspaces are sent to the API, matching the pattern used by other batch mutations (update, favorite, unfavorite). Add four new Storybook stories to cover mixed-state selections and disabled-when-none-eligible cases. Update docs to reflect the new behavior.
Contributor
Docs preview📖 View docs preview for |
aqandrew
marked this pull request as ready for review
July 8, 2026 21:47
ethanndickson
approved these changes
Jul 9, 2026
aqandrew
deleted the
aqandrew/devex-308-bulk-start-should-ignore-already-running-workspaces
branch
July 9, 2026 15:13
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, bulk start required every selected workspace to be stopped, and bulk stop required every selected workspace to be running. Mixed selections disabled both buttons entirely.
every()tosome()so the buttons are enabled when at least one workspace is eligible.Note
Generated by Coder Agents. View session.
Implementation plan
Problem
When an admin selects multiple workspaces and opens the "Bulk actions" dropdown, the Start menu item is disabled unless every selected workspace has
latest_build.status === "stopped". If even one workspace is already running (or in any other non-stopped state), the Start button is grayed out and unusable. Same issue applies to Stop.Changes
1. Relax disabled condition (
WorkspacesPageView.tsx)Changed
every()tosome()for both Start and Stop dropdown items. The buttons are now enabled when at least one selected workspace is in the target state.2. Filter in mutations (
batchActions.ts)Added
.filter()before.map()in bothstartAllMutationandstopAllMutationso only eligible workspaces hit the API. This matches the existing pattern inupdateAllMutation,favoriteAllMutation, andunfavoriteAllMutation.3. Update documentation (
docs/user-guides/workspace-management.md)Replaced "can only be applied to a set of workspaces which are all in the same state" with "apply to eligible workspaces in the selection, skipping workspaces that are already in the target state."
Testing
Four new Storybook stories:
StartIgnoresAlreadyRunningWorkspacesstartWorkspacecallsStopIgnoresAlreadyStoppedWorkspacesstopWorkspacecallsStartDisabledWhenNoWorkspacesAreStartableStopDisabledWhenNoWorkspacesAreStoppable