React-apollo: errorPolicy not working

[Torsten85]

graphql not passing the errors from errorPolicy: 'all' to the props.

As described here: https://www.apollographql.com/docs/react/features/error-handling.html#policies one would assume that there is a errors field next to data when a graphql error occures and the errorPolicy is set to all.

Intended outcome:
There is a error field next to data like this:

const withDataAndErrors = graphql(MY_MIXED_QUERY, {
  options: {
    errorPolicy: 'all'
  },
  props: ({ data, errors }) => {
     // we get data and errors (when they occure) 
  }
});

Actual outcome:
There is no query data and also no errors

That there is no data at all is related to https://github.com/apollographql/apollo-client/issues/2703

Version

• [email protected]
• [email protected]

[AndrewGibson27]

Replicable via this repository.

[nfantone]

Agree with above ☝️ . Either the wording on the docs is confusing or this is a bug.

[rosskevin]

PRs are welcome everyone - all help is appreciated.

[nfantone]

@rosskevin Believe there needs to be, at least, some kind of triage or answer from owners/collaborators before someone puts effort into building/fixing something. Is this really a bug? Is it expected behaviour? Is it documented anywhere? Why is it occurring? Who can give support?

[rosskevin]

@nfantone I understand the frustration, but this is open source. I'm a volunteer as are others, so we have to fix our own problems. I'm just now getting involved and trying to help with maintenance. Given this has a reproduction case and the intended outcome does not match the actual outcome - it seems like it may be a bug - but unfortunately I don't have time to dive into that on your behalf.

[nfantone]

@rosskevin I know where you're coming from. I understand. I'm lucky enough to be the maintainer of a couple of open source projects myself. And I know it's not always an easy task and it demands time.

However, it's not on _my_ behalf (even though I'm not even the one who opened the issue). It's on behalf of the _project_. This discussion has been around forever. I honestly believe your mental model should stay away from "this is open source, send a PR, I don't have time". You cannot expect people to help you out if you don't pour that same amount of effort into it yourself. It's a matter of synergy and feedback loop.

I appreciate you taking the time to answer here, since no one else did.

[amok]

experiencing the same problem
it would be awesome if some contributor can take a look at this and fix the issue in a right way

---

for those who are interested in a fast-dirty-dontuseit workaround
it works for me and hope it doesn't break anything)

apollographql/apollo-client/issues/2703 followup

react-apollo-monkey.js

import { graphql as _graphql } from 'react-apollo'
import { DataStore } from 'apollo-client/data/store'
import { QueryManager } from 'apollo-client/core/QueryManager'

let patched = false // just in case

if (!patched) {
  const fetchRequest = QueryManager.prototype.fetchRequest
  QueryManager.prototype.fetchRequest = function (args) {
    this.dataStore.___errorPolicy = args.options.errorPolicy
    return fetchRequest.call(this, args)
  }

  const markQueryResult = DataStore.prototype.markQueryResult
  DataStore.prototype.markQueryResult = function (
    result,
    document,
    variables,
    fetchMoreForQueryId,
    ignoreErrors
  ) {
    const monkeyIgnoreErrors = typeof this.___errorPolicy === 'undefined'
      ? ignoreErrors
      : ['ignore', 'all'].includes(this.___errorPolicy)

    return markQueryResult.call(this,
      result,
      document,
      variables,
      fetchMoreForQueryId,
      monkeyIgnoreErrors
    )
  }

  patched = true
}

export const graphql = (document, operationOptions) => (...args) => {
  const comp = _graphql(document, operationOptions)(...args)
  const mapResultToProps = operationOptions.props

  comp.prototype.calculateResultProps = function (result) {
    let name = this.type === DocumentType.Mutation ? 'mutate' : 'data';
    if (operationOptions.name) name = operationOptions.name;

    const newResult = {
      [name]: result,
      ownProps: this.props,
    }

    const currentResult = this.queryObservable.currentResult()

    if (currentResult.errors) {
      newResult.errors = currentResult.errors
    }

    if (mapResultToProps) return mapResultToProps(newResult)

    return { [name]: result };

  }

  return comp
}

usage

MyCompContainer.js

- import { graphql } from 'react-apollo'
+ import { graphql } from './react-apollo-monkey'

...

graphql(...)(MyComp)

[afonsodelgado]

Experiencing the same problem here. When error policy is set to 'all' with react-apollo: 2.0.4

[arvinsim]

Any updates on this issue?

[twelve17]

I'm not well versed in TypeScript enough to feel comfortable issuing a PR, but I think I found the problem with regards to errors not being set. I debugged this part of the error handling logic:

          const { loading, error, networkStatus } = currentResult;

What I noticed is that currentResult returns errors (plural) not error, but the logic there is looking for the latter:

I changed that line in-place in node_modules/react-apollo/react-apollo.browser.umd.js to look for currentResult.errors (plural):

541                     var loading = currentResult.loading, error_1 = currentResult.errors, networkStatus = currentResult.networkStatus;

That seems to have done the trick in this case, but I wasn't sure if there were other use cases where currentResult.error (singular) is expected? If not, I'd be glad to issue a PR with this tiny change.

The apollo _client_ docs state that the error property is error, singular, not errors. though currentResult is looking at the result from the _server_, which indeed seems to report errors (plural) (apollo _server_ docs). It appears to me that the apollo _client_ library is supposed to eventually report them under error (singular). I wouldn't be surprised if this discrepancy is the cause of the confusion. :)

[twelve17]

I started a PR for this, but I will need assistance sorting out the tests, as the fixture for handling errors seems to be doing double duty: mocking graphql error responses as well as non-graphql errors (e.g. network errors). Assuming both would result in an error property allows this to work, but now that I see that graphql produces errors, and a network error (presumably) produces error, I feel less comfortable changing the tests without screwing something up, or making a bad assumption. Help would be appreciated!

[Torsten85]

@twelve17 I gave a PR also a shot at around the same time as you. https://github.com/apollographql/react-apollo/pull/1630

The problem is how to interpret the sentence "Any errors reported will come under an error prop along side the data returned from the cache or server." from the docs. How should the result look like?

{data, errors}? {data: { error } as array of errors ? Or maybe {data: { errors }}?

[twelve17]

@Torsten85 heh, I ran into the same conceptual problem when trying to sort out the tests in my PR, so I stopped working on it. @rosskevin might you be able to provide any guidance here with regards to errors vs error handling in the client?

[twelve17]

@Torsten85 I've posted a question on the Apollo Slack to see if we can get some guidance. Also, I'd defer to your PR, since you seem better versed at typescript than I am. 😀

[stantoncbradley]

dang running into this issue too :( still no word from any maintainers? @helfer @jbaxleyiii ?

[twelve17]

@stantoncbradley this seems to be fixed in react-apollo 2.1, which was released a few days ago.

[kolengri]

Same issue. But in Query component :( Error prop is empty

[twelve17]

@kolengri it was fixed for me in react-apollo 2.1

[kolengri]

@twelve17 I have 2.1.3. If errorPolicy="all" fetchPolicy="cache-first" or fetchPolicy="cache-only" it's empty

[cooperka]

FYI this is the PR that supposedly fixed it for Query: https://github.com/apollographql/react-apollo/pull/1649. I'm having this problem with Mutation; still trying to wrap my head around it.

[WaldoJeffers]

Still seing this issue with react-apollo v2.1.4. errorPolicy is set to 'all' and fetchPolicy is set to 'cache-and-network', using the query HOC

[deftomat]

Lates react-apollo and error in Mutation component is still empty 😞

[hwillson]

Is anyone still experiencing this issue with react-apollo 2.1.4 and apollo-client 2.3.2? It appears to be fully fixed, but please let me know otherwise. If you are still encountering this issue (with those versions), and are able to provide a small runnable reproduction (ideally created using the error template), that would be awesome! Closing for now - thanks!

[menkveldj]

I am experiencing this error with apollo-client 2.3.5 and react-apollo 2.1.6. Happy to share code with you over PM. More specifically using the new Mutation react component. @helfer @jbaxleyiii @hwillson

Update:
It appears the when using offline mode and optimistic response, the error doesn't come through. If disableOffline=true then the error comes through.

[AmberDean]

I am experiencing this error with apollo-client 2.3.5 and react-apollo 2.1.6 using the graphql function and HOC.

[amacleay]

Is this really resolved? #2253 is tracking an issue which seems substantially similar.

[norbertkeri]

I'm running into this with react-apollo 2.2.4

Disregard this, problem was elsewhere in my code.

[amacleay]

@norbertkeri I am not seeing this, so I'm curious to see why you are. Can you put together a minimal reproduction to demonstrate it?

[SirwanAfifi]

Same issue with Query component.

[norbertkeri]

@norbertkeri I am not so curious to see why you are. Can you put together a minimal reproduction to demonstrate it?

While putting together an example, I realized my error was in another part of the code, sorry.