-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[prebuilds] Introduce 'failed' state for prebuilds #8601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -77,9 +77,9 @@ export class WorkspaceManagerBridgeEE extends WorkspaceManagerBridge { | |
prebuild.error = status.conditions!.timeout; | ||
headlessUpdateType = HeadlessWorkspaceEventType.AbortedTimedOut; | ||
} else if (!!status.conditions!.failed) { | ||
prebuild.state = "aborted"; | ||
prebuild.state = "failed"; | ||
prebuild.error = status.conditions!.failed; | ||
headlessUpdateType = HeadlessWorkspaceEventType.Aborted; | ||
headlessUpdateType = HeadlessWorkspaceEventType.Failed; | ||
} else if (!!status.conditions!.stoppedByRequest) { | ||
prebuild.state = "aborted"; | ||
prebuild.error = "Cancelled"; | ||
|
@@ -89,6 +89,9 @@ export class WorkspaceManagerBridgeEE extends WorkspaceManagerBridge { | |
prebuild.error = status.conditions!.headlessTaskFailed; | ||
prebuild.snapshot = status.conditions!.snapshot; | ||
headlessUpdateType = HeadlessWorkspaceEventType.FinishedButFailed; | ||
} else if (!status.conditions!.snapshot) { | ||
prebuild.state = "failed"; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Suggestion: Here you could also set There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That is a symptom not the actual error. I've discussed with Gero that we are also going to not overwrite actual errors if they exist (in case of multiple stop messages). |
||
headlessUpdateType = HeadlessWorkspaceEventType.Failed; | ||
} else { | ||
prebuild.state = "available"; | ||
prebuild.snapshot = status.conditions!.snapshot; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drive-by comment: You probably want to handle
"failed"
inprebuildStatusIcon
below as well (there is already aStatusFailed
icon you can re-use).Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the number of error cases grows, it becomes harder to enumerate them. One possible way to simplify the API UX is to have a single
error
state and extend it with acause
which is set to a computer readable reason for the failure - TimedOut, RateLimited, FailedToStart, etc. Theerror
message then becomes a human readable string to show in the UI etc.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point @easyCZ. Alternatively, I think we could also special-case the few non-error cases, then consider "all the rest" as errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends how far we want to go. Some failures are due to user issues, some can be due to system issues. I think the it mostly depends if we control all the
clients
which will be interpreting the status (Dashboard, etc) or if some of the clients are/will be out of our control (implementing against an API). In the former case, it doesn't matter much as we can largely reach a shared understanding of what is an error and what isn't. But if an external frontend/server needs toswitch
on these, it may be less obivous to them with a large number of cases.I think this is probs not something we need/should decide now and I don't think it blocks the change.