-
Notifications
You must be signed in to change notification settings - Fork 273
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
refactor: remove error details #5039
Merged
Merged
Conversation
This file contains 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
co-authored-by: tim <[email protected]>
stefreak
force-pushed
the
errors-remove-details
branch
from
September 7, 2023 09:53
5f222c4
to
77abdfc
Compare
stefreak
commented
Sep 7, 2023
Co-authored-by: Tim Beyer <[email protected]>
Co-authored-by: Tim Beyer <[email protected]>
Co-authored-by: Tim Beyer <[email protected]>
Co-authored-by: Tim Beyer <[email protected]>
Co-authored-by: Tim Beyer <[email protected]>
stefreak
changed the title
improvement: WIP remove error details
refactor: remove error details
Sep 8, 2023
stefreak
force-pushed
the
errors-remove-details
branch
from
September 11, 2023 12:43
faad4bd
to
d61c15d
Compare
There is one failing test in the CI. |
vvagaytsev
reviewed
Sep 11, 2023
- Throw GardenError of type "test-failed" or "task-failed" when the actual test or task command failed, e.g. with non-zero exit code. - Do not report "test-failed" or "task-failed" on errors like Pod eviction and on other Kubernetes API errors. Co-authored-by: Tim Beyer <[email protected]>
vvagaytsev
reviewed
Sep 11, 2023
vvagaytsev
reviewed
Sep 11, 2023
vvagaytsev
reviewed
Sep 11, 2023
vvagaytsev
reviewed
Sep 11, 2023
vvagaytsev
approved these changes
Sep 11, 2023
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.
Huge thanks for doing this PR! 👍 :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What this PR does / why we need it:
Remove the
detail
property and constructor argument fromGardenError
.We did this because there were several issues with the
detail
property:GardenError
, thedetail
property misled developers in some cases to conclude that the error message has enough information for users: The contents of thedetail
property are not printed to the screen when an error occurs, and sometimes useful information has not been exposed through the message.detail
property often used to include complex objects, like instances ofGarden
or theSolver
. The error details sometimes have been exposed to the user through the-o yaml
and-o json
output flags, or serialized to JSON either accidentally or on purpose through the WebSocket interface or the Garden Cloud API. This led to issues ranging from bad user experience because of huge amounts of YAML, to OOM crashes when serializing huge amounts of JSON. This in turn led to very hard to maintain work-arounds likesanitizeValue
. One particular big problem withsanitizeValue
is that the return type is only known at runtime so we cannot define a correct TypeScript return type.detail
property is of typeany
by default but there was still a lot of error handling code that relied on particular details to be defined. Due to this issue there were no type errors when changing the details in any way, and that could lead to really hard to understand issues.We addressed these issues with the following changes:
detail
property and constructor argument from theGardenError
ABC.GardenError
. In the error handling code we usedinstanceof
to narrow the type of the error to that subclass, and only then tried accessing the error details.Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer: