-
Notifications
You must be signed in to change notification settings - Fork 170
Investigate proper parsing of API errors on webapp side #337
Copy link
Copy link
Open
Labels
Difficulty/1:EasyEasy ticketEasy ticketGood First IssueSuitable for first-time contributorsSuitable for first-time contributorsHacktoberfestHelp WantedCommunity help wantedCommunity help wantedTech/GoTech/ReactJSType/TaskA general taskA general taskUp For GrabsReady for help from the community. Removed when someone volunteersReady for help from the community. Removed when someone volunteers
Metadata
Metadata
Assignees
Labels
Difficulty/1:EasyEasy ticketEasy ticketGood First IssueSuitable for first-time contributorsSuitable for first-time contributorsHacktoberfestHelp WantedCommunity help wantedCommunity help wantedTech/GoTech/ReactJSType/TaskA general taskA general taskUp For GrabsReady for help from the community. Removed when someone volunteersReady for help from the community. Removed when someone volunteers
Type
Fields
Give feedbackNo fields configured for issues without a type.
The plugin's backend is returning error messages as JSON, making it so the frontend displays the errors as JSON in some cases. These code paths should be reviewed to make sure it is rendered properly when we display the errors in different components.
The frontend should be resilient to the possibility that the error is not structured as JSON as well.
Original comment:
This PR is a quick resolution for this issue, however, I believe that it will still need to be further examined and the changes from stringified error to parseable object error should happen in the function that receives the error, not in the method that renders it. Therefore, I believe that still needs to change for this issue to be complete, either in this PR, or if further consistency between error objects across the webapp and the server need to be examined then possibly in the scope of another issue.
Originally posted by @aidapira in #333 (comment)