apollo-client: React Native Uncaught Error, Network Request Failed

Issue Description

When using the subscribe function

try{
                        await ApolloClient.subscribe<GQLSubscription>({
                            query: gql(/* GraphQL */ `
                                subscription {
                                    postUpdated {
                                        ID
                                        rooms
                                    }
                                }
                            `),
                            errorPolicy: "all",
                            context: {
                                uri: "http://graphql.test/wp-json/api/graphql",
                            },
                        }).subscribe((value) => {
                            console.log("subscribe", value);
                        });
}catch(e){

}

If the network is gone or any error happens it is thrown outside my catch! Even though errorPolicy: "all", shouldn’t throw at all, it happens even if I disable all the links:

        globalThis.ApolloClient = new OApolloClient({
            cache: new InMemoryCache({}),
            uri: "http://dummy.test",
        });

It’s works fine for query, and mutation just the subscribe throws that weird uncatchable error!

Link to Reproduction

https://github.com/Stevemoretz/apollo-bug

Reproduction Steps

git clone https://github.com/Stevemoretz/apollo-bug
cd apollo-bug
yarn install
npx expo start

Press i for iOS and a for Android, after it opens up you’ll see a button:

Press it and you’ll get :

Here’s the whole code: https://github.com/Stevemoretz/apollo-bug/blob/main/App.tsx

About this issue

Original URL
State: closed
Created a year ago
Reactions: 3
Comments: 21 (12 by maintainers)

Most upvoted comments

Hey @marfrede 👋

No updates yet, but now that we have 3.8 out the door, we can look at pulling this in to our next set of bug fixes. Thanks for the nudge!

jerelmiller on Aug 21, 2023

@jerelmiller Are there any updates on this Issue??

I created another Issue (Issue: For subscriptions, the errorPolicy setting does nothing) for this at https://github.com/kamilkisiela/apollo-angular/ before I knew that the problem actually originated here (@apollo/client).

marfrede on Aug 21, 2023

Ok great!

As for the behavior, it should be identical to how queries work. Refer to the error policy documentation for an overview of the differences and why you might use each.

In practice, I would see it working something similar to this:

client
  .subscribe({ errorPolicy: 'none' }) // the default
  .subscribe({
    next: () => // not called
    error: () => // called since errors are encountered
  })

client
  .subscribe({ errorPolicy: 'ignore' })
  .subscribe({
    next: ({ data, errors }) => // called when an error is encountered. `errors` property is not set
    error: () => // not called
  })

client
  .subscribe({ errorPolicy: 'all' })
  .subscribe({
    next: ({ data, errors }) => // called when an error is encountered. Both `data` and `errors` are available
    error: () => // not called
  })

jerelmiller on Feb 21, 2023

Ahhhhhh I finally found where you’re seeing that: https://github.com/apollographql/zen-observable-ts/blob/main/module.d.ts#L14

That zen-observable-ts package is one that we use internally as a thin wrapper around zen-observable. From what I’m reading, it looks like that start function is actually incorrect. I don’t see that available anywhere in the actual zen-observable package. I’ll file an issue over there to see if that function can be removed from the interface. This would explain why its not being called in your case 😆 .

At this point, we might be getting a little bit far from the original issue which is that the errorPolicy is ignored for subscriptions. Apologies on my part, this was interesting conversation!

If adding the ability to detect when the subscription is connected is something you’re passionate about, could you add a feature request over in our feature requests repo? This would be a great place to continue this conversation and nail down the use cases for this potential feature add.

As for this bug, we will get to it when we get a chance! Thanks for bringing this to our attention.

Thank you for explaining that and submitting that issue over there, actually errorPolicy is related to this exact thing, so we don’t need another feature request if the errorPolicy would be implemented, on all the other requests (query and mutation) if that request passes then we can access the data and if it fails it returns the error or throws an error object so in those cases we are covered and if errorPolicy gets implemented for this too, I’d suppose the behavior should be the same, so we should be able to even get the data as well as knowing it was a successful request, unless it would be implemented differently which would make my statement completely wrong.

Stevemoretz on Feb 21, 2023