refactor: simplify workspace start status management #222
+56
−51
Conversation
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
Current approach with a secondary poll loop that handles the start action of a workspace is overengineered. Basically the problem is the CLI takes too long before moving the workspace into the queued/starting state, during which the user doesn't have any feedback. To address the issue we: - stopped the main poll loop from updating the environment - moved the environment in the queued state immediately after the start button was pushed. - started a poll loop that moved the workspace from queued state to starting space only after that state became available in the backend. The intermediary stopped state is skipped by the secondary poll loop. @asher pointed out that a better approach can be implemented. We already store the status, and workspace and the agent in the environment. When the start comes in: 1. We directly update the env. status to "queued" 2. We only change the environment status if there is difference in the existing workspace&agent status vs the status from the main poll loop 3. no secondary poll loop is needed.
And improved debug messages
Start action was still visible because the action list was not yet refreshed.
code-asher
reviewed
Nov 21, 2025
Comment on lines
+263
to
+267
| if (WorkspaceAndAgentStatus.from(this.workspace, this.agent) == WorkspaceAndAgentStatus.from( | ||
| workspace, | ||
| agent | ||
| ) | ||
| ) { |
Member
There was a problem hiding this comment.
I think checking the status is subtly different from checking if there is a new build, because imagine this scenario:
- Latest build is
failed. - The poll runs, so we currently have
failedstored as the status. - User starts workspace, we set to
queued. - Build fails again (a brand new build, but it is also failing).
- Poll runs again, checks
failedagainst the last status, which is alsofailed, so it leaves the status asqueued, even though the workspace is actually failed currently, so really we do want to update the state tofailed.
So we could miss updates from one build to another build when both builds end up with the same status.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Current approach with a secondary poll loop that handles the start action of a workspace is overengineered. Basically the problem is the CLI takes too long before moving the workspace into the queued/starting state, during which the user doesn't have any feedback. To address the issue we:
@asher pointed out that a better approach can be implemented. We already store the status, and workspace and the agent in the environment. When the start comes in: