The internal API Client middleware pipe includes an error handling stage, so any errors encountered during the internal request will not result in thrown exceptions. Because calling code often assumes that the response is valid (and doesn't check for all possible errors), when an error does occur in the internal request, the calling one often fails when trying to get response data.
Related: flarum/framework#2893
Expected Behavior
If an exception is thrown in an internal API client request, that exception should propogate up to the calling request's error handler.
Possible Solutions
There are two ways we could achieve this:
Remove the error handler layer from the API client's middleware stack
Add a switch statement checking the API client's response code, and throw errors manually
I think (1) is better, since it will give us access to the error's call stack.
Challenges
Unfortunately, we can't make this change now because it would break the Registration/Login/etc controllers. These are located in the forum namespace, so they use the View/Whoops error formatters, but the frontend interacts with them as if they used the JSON formatter from the API namespace. If we throw exceptions in them, we'll get a whoops error page, which is useless to the SPA when trying to register. So before we can fix this issue, we need to find a way to use the JSON error formatter with this group of routes while keeping them under the forum namespace.
Current Behavior
The internal API Client middleware pipe includes an error handling stage, so any errors encountered during the internal request will not result in thrown exceptions. Because calling code often assumes that the response is valid (and doesn't check for all possible errors), when an error does occur in the internal request, the calling one often fails when trying to get response data.
Related: flarum/framework#2893
Expected Behavior If an exception is thrown in an internal API client request, that exception should propogate up to the calling request's error handler.
Possible Solutions There are two ways we could achieve this:
I think (1) is better, since it will give us access to the error's call stack.
Challenges
Unfortunately, we can't make this change now because it would break the Registration/Login/etc controllers. These are located in the forum namespace, so they use the View/Whoops error formatters, but the frontend interacts with them as if they used the JSON formatter from the API namespace. If we throw exceptions in them, we'll get a whoops error page, which is useless to the SPA when trying to register. So before we can fix this issue, we need to find a way to use the JSON error formatter with this group of routes while keeping them under the forum namespace.
See flarum/issue-archive#38