Skip to content
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

networkError method should define a request attribute in mocked error response #168

Open
tiagobnobrega opened this issue Oct 14, 2018 · 5 comments · May be fixed by #264
Open

networkError method should define a request attribute in mocked error response #168

tiagobnobrega opened this issue Oct 14, 2018 · 5 comments · May be fixed by #264
Labels

Comments

@tiagobnobrega
Copy link

When calling networkError, the error returned by the lib should define a request attribute. This is how axios works. It's important because error handling rely on the error.response check. Such as:

.catch((error) => {
        // Error
        if (error.response) {
            // The request was made and the server responded with a status code
            // that falls out of the range of 2xx
            // console.log(error.response.data);
            // console.log(error.response.status);
            // console.log(error.response.headers);
        } else if (error.request) {   //    <--------- THIS CHECK
            // The request was made but no response was received
            // `error.request` is an instance of XMLHttpRequest in the browser and an instance of
            // http.ClientRequest in node.js
            console.log(error.request);
        } else {
            // Something happened in setting up the request that triggered an Error
            console.log('Error', error.message);
        }
        console.log(error.config);
    });

I've managed to workaround this by replying [0,'Network Error']. But, I guess it's not the ideal solution.

@ctimmerm ctimmerm added the 2.0 label Dec 26, 2018
@Grant-Lay
Copy link

+1

1 similar comment
@iliyanyotov
Copy link

+1

@dreyks
Copy link

dreyks commented Apr 21, 2020

@tiagobnobrega how did you manage to workaround this? replying with [0, 'Network Error'] returns an error with both response and request set, so that'd trigger the if (error.response) branch

actually it puts request inside response, not adjacent

@tiagobnobrega
Copy link
Author

@dreyks What I do is normalize error object to always have a statusCode attribute as a root property. it first tries to take the status from the response, then checks for request and finally defaults to some code. This way, even if it has a response with a status of "0" (zero). That code will be defined. I currently have this (in typescript):

interface RequestError extends AxiosError {
  status: number;
  data?: object;
}

function normalizeRequestError(error: AxiosError): RequestError {
  const {response, request} = error;
  if (response) {
    /*
     * The request was made and the server responded with a
     * status code that falls out of the range of 2xx
     */
    const {data, status: responseStatus} = response;
    return {
      ...error,
      status: responseStatus, // <- This would be zero in the mock returning [0, 'Network Error']
      data,
    };
  } else if (request) {
    /*
     * The request was made but no response was received, `error.request`
     * is an instance of XMLHttpRequest in the browser and an instance
     * of http.ClientRequest in Node.js
     */
    return {
      ...error,
      status: 0, //<- also set to zero in actual code
    };
  } else {
    //* Something happened in setting up the request and triggered an Error
    return {
      ...error,
      status: -1,
    };
  }
}

@devinpitcher devinpitcher linked a pull request May 19, 2020 that will close this issue
@PhakornKiong
Copy link

Would like to know if there is any progress on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants