-
-
Notifications
You must be signed in to change notification settings - Fork 9.2k
useAPIErrorHandler: Reverse error handling (API -> Axios) #16162
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
Conversation
|
Size Change: +89 B (0%) Total Size: 1.52 MB
ℹ️ View Unchanged
|
Codecov ReportPatch coverage has no change and project coverage change:
Additional details and impacted files@@ Coverage Diff @@
## main #16162 +/- ##
==========================================
+ Coverage 59.95% 66.25% +6.29%
==========================================
Files 1485 1103 -382
Lines 37419 22654 -14765
Branches 7518 4183 -3335
==========================================
- Hits 22435 15009 -7426
+ Misses 12780 6757 -6023
+ Partials 2204 888 -1316
Flags with carried forward coverage won't be shown. Click here to find out more. see 382 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
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.
LGTM, tested also with the code in the DEITS branch #16006
|
This pull request has been mentioned on Strapi Community Forum. There might be relevant details there: https://forum.strapi.io/t/displaying-custom-error-message-in-admin-ui-in-strapi-4-8-x/27644/2 |
What does it do?
Reverses the
AxiosErrorhandling ofuseFormatAPIError. Instead of normalizingAxiosErrorbefore the response error, it should work the other way around.Why is it needed?
I made a conceptual mistake in #16090. Axios always throws an
AxiosErrorregardless if the error origin is the network or an HTTP response code. Therefore we have to check first, whether the API returned an error (e.g.ValidationError), and only if this error can not be normalized, we should try and normalize the AxiosError.The error response is always more specific and should therefore have more priority.
Related issue(s)/PR(s)