refactor: simplify workspace start status management #222
+72
−66
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
needed when comparing two builds
when updating the workspace and agent. Checking the status is subtly different from checking if there is a new build in the following scenario: 1. Latest build is failed. 2. The poll runs, so we currently have failed stored as the status. 3. User starts workspace, we set to queued. 4. Build fails again (a brand-new build, but it is also failing). 5. Poll runs again, checks failed against the last status, which is also failed, so it leaves the status as queued, even though the workspace is actually failed currently, so really we do want to update the state to failed. So we could miss updates from one build to another build when both builds end up with the same status.
code-asher
approved these changes
Nov 25, 2025
Member
|
One thing I realized, is that suppose the cli start command fails for whatever reason and never submits a build, should we mark the workspace as failed? Or go back to the previous 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: