How to effectively handle 404/500 http errors in server-side rendering web application which uses store for state

error handlingif statementreactjsredux

I'm working on a website using server-side rendering approach. I'm using React and Redux for this. Redux handles the state of the application and provides API to change the state. All asynchronous data fetching is done via Redux.

The problem is that a URL may be like example.com/news/:param where param is some dynamic parameter like a country for example. In React I have a page which is common to all news pages so because the URL path starts with news react-router will find a page for it. However, if a user enters a non-valid country 404 page should be returned. Whether a country or any other param is valid can only be determined via a request to the API service I'm using, that is using Redux actions.

Another complication is that a given page may need to make several requests to the API in order to fetch data. If param is found in the API but some other less important data is not found I don't want to display 404 page. 404 page should therefore displayed only if the "main" request to the API returns 404.

Current solution:

So far in "main" requests to the API, I tentatively switch on notFound variable. That is I suspect that a request which contains an param potentially may result in 404 because the param was not found. So if such request indeed results in 404 status then my main component in React detects that notFound is now true and shows the default Not Found page to the user.

In addition I have a variable in Redux state which is called internalError. It is set to true if some internal error occurred, often as a result of a request to API, e.g. JSON parsing error, etc. internalError is always the opposite boolean value of notFound. This way when we are in the main reducer which calculates the new values for internalError and notFound then if notFound is false then error will be true and this way we know that we need to display 500 error to the user instead of 404.

This approach has several issues:

Race condition between Redux actions which set notFound to true and Redux actions that set notFound back to false.
Imagine a situation when 500 error may occur due to some unimportant Promise rejection (thus setting internalError to true) but later another API request will return 404 for the requested param. So first the user will see a generic error page with 500 status then a Not Found page. It's another race condition.

I'm wondering if there's a simpler, better approach.

Best Answer

If you're working on a server side rendered app, redux and react router seem like the wrong tools for you. The reason you're having difficulty is because you're taking a reasonably state-light operation (web requests and responses) and inserting a heavy duty state management tool (Redux) inside of it.

Similarly, it seems like you're using react router, a front end route handler, when standard back end route management would suit your project fine.

You're using SPA/JAM stack tooling that is great for lightweight, single purpose views but it seems like the project is at a point where owning serverside behavior is a given. You can reimplement HTTP on top of HTTP or just use standard HTTP tooling to solve these problems.

The easiest approach would probably be to use a small express or similar lightweight web server for your project, and implement your requests as standard urls. Implementing your API calls as async requests that all need to finish before returning a single response will make a much simpler system than managing all of their states independently, like Redux allows you to.

Related Solutions

What are the definitive guidelines for custom Error Handling in ASP.NET MVC 3

I'll share the way I ended up doing this, that was part of the original question.

First, the problems I encountered:

With customErrors on (i.e. in production) the global HandleError attribute swallows exceptions and renders your error view, but then you can't log it with an addon tool like elmah, since elmah never sees it. You could log it in your view I suppose, but it's a view, that seems wrong. The global HandleError attribute appears new in the MVC 3 RTM Visual Studio project template.
customErrors with urls for MVC endpoints returns 302 status codes. There is the redirectmode property, but you cannot match mvc urls in customErrors and use the ResponseRewrite mode. ( https://stackoverflow.com/questions/781861/customerrors-does-not-work-when-setting-redirectmode-responserewrite/3770265#3770265 )
Avoiding customErrors completely and handling everything custom in your app leads to a lot of complexity, IMO. (Iloved this: https://stackoverflow.com/questions/619895/how-can-i-properly-handle-404s-in-asp-net-mvc/2577095#2577095 , but it wasn't right for our project)

My solution

I've taken MVC out of the equation completely. I've removed HandleErrorAttribute global filter in global.asax and focus entirely on the customErrors configuration, shifting it to use WebForm redirects and change to redirectmode to ResponseRewrite in order to avoid the 302 HTTP response codes.

<customErrors mode="On" defaultRedirect="/Error.aspx" redirectMode="ResponseRewrite">
  <error statusCode="404" redirect="/NotFound.aspx" />
</customErrors>

Then, in NotFound.aspx page_load event, set the Response.StatusCode to 404 and in Error.aspx set the code 500.

Results:

The goals for both have been achieved with the Elmah logs, the friendly error page, and the status code with one line of code on the code-behinds. We're not doing it the "MVC Way" as the earlier solution does, but I'm OK with that if it's two lines of code.

Should REST API Return 500 Error for Non-Existent Object Queries?

I think a 404 response is the best semantic match here, because the resource you were trying to find (as represented by the URI used for the query) was not found. Returning an error payload in the body is reasonable, but not required.

According to RFC 2616, the definition of the 404 status code is:

10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

Best Answer

Related Solutions

What are the definitive guidelines for custom Error Handling in ASP.NET MVC 3

Should REST API Return 500 Error for Non-Existent Object Queries?

Related Topic