-
Notifications
You must be signed in to change notification settings - Fork 783
Unhandled Network Error #604
Comments
may this relate ? |
@maxtechera thanks! Could you provide more information, like a stack trace or a reproduction using react-apollo-error-template? That would help us fix the issue faster. |
Closing since this has been longer than 2 weeks without a reproduction. If it is still an issue, feel free to reopen! |
This happens for me too. All you have to do is kill your graphql server and try running a query in react native. It will throw an unhandled error. I was trying to mimic the server being down and see how I was supposed to handle errors. Not sure how this isn't an issue for others? |
Yeah same for me ! I have absolutely no idea how to handle down server. When I open my app in Airplane mode it's just crashing... |
How are we supposed to catch exceptions from this? Any ideas @jbaxleyiii |
Same for me. In my case, I attach a jwt token in header for apollo client. Whenever the jwt token is expired, server side return error json with status equal to 401, and I got 'Unhandled (in react-apollo)', 'ApolloError . |
I solved this by handling exception on main page where the apollo-query has been executed.
|
This is horribly repetitious. I don't want to have to do that. I want to catch all these in my top level component and throw up an alert view, otherwise every render method I have to do this. Or make a higher order component in front of the component making the query. |
Hello, Here is a repo to reproduce the error https://github.com/sabativi/apollo-offline-network-error Also to look at the problem here is a video record : http://recordit.co/DrPPhE4Fof. Hope it will help @helfer |
Hey, I had posted a repo to reproduce more than one week ago and still do not have any feedback. |
Hello, |
Hi @sabativi sorry I didn't respond earlier, I don't always have time to check issues every day. Thanks a lot for the reproduction, it helped me quickly figure out what is going on. In essence, Here's a complete example: class App extends Component {
render() {
const { data: { refetch, loading, hero, error } } = this.props;
if(loading) {
return (<p>Loading…</p>);
}
return (
<main>
<header>
<h1>Apollo Client Error Template</h1>
<p>{error && error.message}</p>
<h3>{!error && hero.name}</h3>
<button onClick={() => refetch().catch(e => null)}>
Refetch
</button>
</header>
</main>
);
}
} I hope it helps! 🙂 PS: I'm happy to discuss changing this behavior in a future major version of the API, but for the time being we have to keep it because it would be a breaking change to remove it. |
@helfer This still is not a solution to the problem. In my render method, if I do this: let { vaults, refetch } = this.props.data; And an error occurs, a big red box shows up saying unhandled network error. If I simply change it to destructure and pull out the error, it works: let { vaults, refetch, error } = this.props.data; This is pointless, because either way, I have after middleware catching all errors at the network interface level. Apollo should not be telling me the exception is uncaught when I am logging it in the network interface middleware. As I mentioned earlier, myself and many others do not want to add error handling on every component. Without this being fixed, we have to manually check for an error inside every component that makes a query. |
@helfer You stated, that one needs to handle the error when it should not be thrown. Is there a possibility to do so when using the react-apollo Because one can't catch on the component. |
Indeed this is the problem I was trying to show by using a refetch when offline, but obviously was not a good choice... |
same here. the call works in GraphiQL but not using anyone know how to solve it? |
Hey @vincentpageau, I'll let @jbaxleyiii give you the authoritative answer on that, but I believe the way to "handle" the error when using the |
@helfer I would love to get rid of that check! Haha |
@helfer @jbaxleyiii So basically when the
I'm using this at the moment and the
Thank you for your patience^ |
Jesus, is there no way around this? |
I don't think Jesus is among us |
Setting error policies on the client solved it for me. const apolloClient = new ApolloClient({
...
defaultOptions: {
watchQuery: {
errorPolicy: 'none'
},
query: {
errorPolicy: 'none'
},
mutate: {
errorPolicy: 'none'
}
}
}) |
Thank you @gastonmorixe, I'm gonna try that out — setting it on each query, even if accessing |
@Amnesthesia I am with you there, it is hell on RN. Good luck. |
* downgrade apollo to circumvent bug Running into this issue: apollographql/apollo-client#3236 * Fix network error catching apollographql/react-apollo#604 (comment) 5648596 * fix refetch/fetchmore handlers when null * make sure errors are passed through on nested HOCs * improve error handling on profile * fix linter * update snapshots * add audio error handling
Hey @mjasnikovs 👋, were you able to properly catch 401 exceptions? I'm already accessing |
@diegocouto I ran on a similar issue while using Take a look at this issue: apollographql/apollo-link#542, might help you in some way... |
@diegocouto Hi, enjoy this pain. Apollo products like trowing errors randomly by design. So enjoy this ride. I made this weird looking component. It is working for me. :/ import React from 'react'
import PropTypes from 'prop-types'
import {Message} from 'semantic-ui-react'
const Errors = ({errors}) => {
if (!errors) {
return null
} else if (Array.isArray(errors.graphQLErrors) && errors.graphQLErrors.length) {
return <Message negative>
<Message.Header>Kļūda</Message.Header>
<p>{errors.graphQLErrors.map(val => val.message).join(<br />)}</p>
</Message>
} else if (errors.message) {
return <Message negative>
<Message.Header>Kļūda</Message.Header>
<p>{errors.message}</p>
</Message>
}
return null
}
Errors.propTypes = {
errors: PropTypes.oneOfType([PropTypes.object, PropTypes.bool])
}
export default Errors Then <Query query={DRAWINGS_CATS_Q}>
{queryState => {
if (queryState.error) {
return <Errors errors={queryState.error} />
} |
@gastonmorixe @Amnesthesia @jbaxleyiii What is the solution to stop this error in react native, even when accessing the error and I respect that the opinion is that errors should be handled explicitly, but this is not documented and the solution is unclear and it crashes React Native apps easily, something should be done about this. At least a proper documentation, or better an option to switch it off via a flag in the client. |
Do I have to switch to the new |
Seems that replacing the |
In react native using the Query component i only have this error when doing a refetch or fetchMore. If it's just the normal query, it handles everything fine. I tried all the solutions excluding using a HOC, nothing worked for refetch or fetchMore. |
@MrLoh, in the end I could still make it fail with the render props, just not as often. My project is react native so it was particularly visible, however in the codesandbox sample, it helps to open up the console to see the exceptions. Looking at the code, both APIs wrap the basic query so you could roll your own. Must admit I haven't tried it with the basic client.query yet. |
I'm having the same issue here, no way of catching the network errors with Apollo. Every time I switch off the internet connection I get the red screen error no matter which solution I try. @MrLoh can you share the HOC you created? I'd love to test if it works for me too. |
+1. I'm not getting a red screen, but even after accessing props.data.error in a component wrapped in the HOC component 'graphql' I'm getting a "Possible Unhandled Promise Rejection: Error: Network error: Network request failed" in React Native |
@404sand808s I'm also looking for a easier way to retry (all kinds of) operation, did you found any? |
@rankun203 sadly no, not yet. |
An irrelevant comment has been moved to stack overflow. |
@rankun203 this seems to have nothing to do with this issue. Please don’t pollute issues with random related questions, but use stack overflow. |
@MrLoh That's reasonable, sorry for putting wrong discussions here. |
My issue is when I navigate to a route, at this moment At It does't make sense that handle the I want to intercept the error and stop mount function errorHandler({ graphQLErrors, networkError }) {
if (graphQLErrors) {
graphQLErrors.map(error => {
if (error.code === 1001) {
auth.signout();
window.location.replace('#/login');
//TODO: stop here!! Don't mount component and navigate to '#/login' route
}
});
}
if (networkError) {
if (networkError.statusCode === 401) {
auth.signout();
window.location.replace('#/login');
}
}
} |
So if you're offline, component blows up in ReactNative, it does latch the error to the error prop afterwards. My setup is pretty default, using @immortalx i remember reading that if you're refetch is failing then you need to latch on catch at the end of that edit: Turned out deconstructing was the issue, oops.
|
There is another solution that involves accessing the error for any query/mutation by wrapping the export const graphql = (document, operationOptions) => {
const origHof = origGraphql(document, operationOptions)
return (WrappedComponent) => {
const CustomGraphqlWrapper = (props) => {
let handler = null
if (
(!operationOptions || !(handler = props[operationOptions.name])) // if named handler not defined continue checking
&& !(handler = props.data) // if unamed query handler not defined keep checking
&& !(handler = props.mutate) // if unamed mutation handler not defined then we know not try accessing an error
) {
return origHof // we aren't decorating the wrapped component with a handler, so no error needs accessing
}
if (handler.error) {
console.log('GraphQL Request Error', handler.error)
}
return <>
<WrappedComponent {...props} />
</>
}
return origHof(CustomGraphqlWrapper)
}
} |
Steps to Reproduce
Describe how to reproduce this issue.
Buggy Behavior
Unhandled promise rejection stops the execution of the app.
Expected Behavior
Component should render without data and errors received through props. The same when its a query error or some kind of http error.
Version
The text was updated successfully, but these errors were encountered: