Audit error handling in actions and state

[nathanielrindlaub]

We need to be able to support consuming & storing GraphQL errors produced by the API in our application state, as well as errors thrown internally on the client side (for example, if we lose internet connection during a bulk upload and need to notify the user that the upload was aborted).

For the most part, I think we have good support for the GraphQL errors arrays and those are the most common, but we have poor and inconsistent handling when throwing new Error()'s internally. Issues and observations so far I've noted are:

• graphql-request's default error policy is to throw an error if the response from the GraphQL resolver includes anything in the payload's errors array. That's fine (I think), but worth noting that even is some successful mutations or queries occurred and errors.length > 0 but there are also some data in the data part of the payload, we aren't able to do anything with that data unless we change the errorPolicy to errorPolicy: 'all'. So for now, if any errors are returned from the API, graphql-request throws them, the call() function re-throws them as well, and then they enter the catch blocks of whatever Thunk made the request.
• ErrorAlerts.js expects errors in state to be arrays, but it's not clear that's always the case for errors thrown on the client-side
• Redux complains about there being non-serializable data in payloads when passing along a client-side-created Error class instances into Redux action creators e.g. uploadFailure(new Error('error message')). So we need to figure out a way to normalize/coerce client-side into GraphQL errors arrays before they get included as payloads in dispatched actions. Something along these lines in Thunk catch blocks perhaps?

    if (!Array.isArray(error)) {
      // if the error is a network-related error and thrown on the client side
      // (e.g., we lost internet connection and exhausted upload retries)
      // we need to re-format the error to match GraphQL errors array and error objects
      errors = [{ message: error.message, extensions: { code: 'UPLOAD_FAILED' } }];
    }

Related: https://github.com/tnc-ca-geo/animl-api/issues/147

It also might be worth looking into abandoning graphql-request for Apollo-client. Apollo-client has built in handling for network errors, but I believe that refers to server-side network errors, not client side.

[nathanielrindlaub]

Also worth trying to improve ErrorAlerts.js - in particular it feels onerous and redundant to create error dismissing actions and reducers for each type of error. e.g.:

    dismissUploadError: (state, { payload }) => {
      const index = payload;
      state.loadingStates.upload.errors.splice(index, 1);
    },

There must be a way to abstract that a bit, maybe by adding an extraReducers case to each slice to handle a more generic dismissError kind of action?

[nathanielrindlaub]

And make sure all ErrorAlerts are wired up while we're at it...