Skip to content

bug(site): UI for batch-updating workspaces is confusing and has destructive race conditions #18879

@Parkreiner

Description

@Parkreiner

Blocks coder/internal#681

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

I'm making this issue for documentation purposes (mostly to explain why 681 is taking me so long). But I'm hoping to have all PRs for this opened up for review by end of day today. Had most of this done ~2 weeks ago, but then Registry stuff side-tracked me.

For context, the UI I'm talking about is what you see when you select multiple workspaces on the /workspaces route, and then click Batch Actions -> Update...

Image

I'm just going to itemize a list of all the issues I found when trying to figure out if I could build on top of this UI for 681:

Problems with the current implementation

To be clear, I don't want to point any blame at anybody else for this. I was tagged on the PR that brought this functionality in, and I approved it. I'm very much blaming myself here.

  • As you can see in the screenshot, I have four workspaces selected, but there's only mention of one workspace being updated
  • In addition, even though the UI says "Update 1 workspace", it doesn't tell you which workspace that will be. It only tells you the name of the template. If you have multiple workspaces that use the template, you have no idea which one will be updated
  • If there are any workspaces that are already up to date, they'll implicitly be dropped from the UI, with no feedback telling you that you're already good to go
  • If you try to batch-update a list of workspaces that is 100% up to date, you see this:
    • Image
  • The actual UI is a multi-step wizard that, depending on the state of the workspaces, forces you to go through multiple modal screens before being able to update anything. Wizards are generally bad for accessibility, but this also feels incredibly overbearing for a UI element that's meant to be a convenience tool
  • If you try to update running workspaces, that's obviously risky, and the wizard tries to shield you from that. If there are any running workspaces, the UI will add an additional screen to add more friction for updating things
    • The problem is that the checks don't account for transitioning workspaces, so if you start a workspace, and then quickly batch-update it, the wizard won't give you the extra screen yet
  • The wizard logic is defined via an incredibly fragile useEffect call that disables a bunch of warnings. In practice, this means that the screen that you're on in the wizard can randomly jump around over time, without the user doing anything
  • The current implementation treats our React Query cache like free real estate, and puts a puts a bunch of data that is only relevant for this one component into global state. The functions being cached are also based on our template API calls, but because we're using ad-hoc query keys, none of the results can be reused for other pages, even though there should be nothing stopping that
  • The error-handling logic checks the wrong properties for our queries, and stale errors can prevent the UI from being able to work, even if everything is fine
  • The current implementation has some needless React state that actually makes performance worse
  • The main underlying implementation uses a bunch of <div>s and doesn't have much to help screen readers
  • The UI is currently wired up to ALWAYS trigger data fetching for the batch updates when the component first mounts, even if the wizard is closed. This means that we're firing off a bunch of API calls that won't be used 99% of the time
  • The actual modal window is incredibly small, and often leads to a lot of awkward text wrapping

Expected Behavior

All problems listed above are removed. For the running workspaces specifically, the form does not let you submit anything while workspaces are actively transitioning into a new workspace build state.

Steps to Reproduce

  1. Go to the /workspaces in the website
  2. Select any number of workspaces with various states (dormant, actively running, outdated, not outdated, etc.) with the checkbox UI
  3. Make sure that all workspaces are done transitioning
  4. Try to open the Batch Update UI
  5. See all the problems listed above

Environment

  • Host OS: MacOS Ventura 13.6.7
  • Coder version: v2.24.1-devel+dad033ee3

Additional Context

I have tested this on the latest version

Metadata

Metadata

Assignees

Labels

s2Broken use cases or features (with a workaround). Only humans may set this.

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions