loading is false, but no data is present (and no error)

[adamdonahue]

Just upgraded to Apollo 2.0, using react-apollo 2.0.0 -- it now appears that the graphql props option for a query is passed a data argument that can have loading set to false but no data.

That is, given a query, say:

query X($id: ID!) {
  myItem(id: $id) {
    id
    field
  }
}

and a graphql call:

graphql(query, {
  props({ data: { loading, error, myItem } }) {
    console.log('loading =', loading);
    console.log('error =', error);
    console.log('myItem =', myItem);
    return { ... }
 }
})(MyComponent)

We're seeing the output:

loading = true
error = undefined
myItem = undefined
loading = false
error = undefined
myItem = undefined
loading = false
error = undefined
myItem = {<data>}

That is, there is an interim state between loading having been set to false but myItem yet available on the data argument.

Is this expected, as it appears to differ from the behavior of Apollo 1.0. And if so, what is the reliable way to check that data was loaded and is ready for use in the component?

We're now using (loading || !myItem) to check whether something is loading.

[Panoplos]

I can confirm this issue exists.

Offending code:

 graphql(
    gql`
      query localise($locale: LocaleType!, $resourceIds: [String]) {
        l10nSlugs(locale: $locale, resourceIds: $resourceIds) {
          id
          resourceId
          slug
        }
      }
    `,
    {
      name,
      options: ({ locale }) => ({
        variables: {
          locale,
          resourceIds
        },
      }),
      props: props => ({
        l10n: {
          /**
           * Whether or not the graphql resource is loading.
           */
          loading: props[name].loading,
          /**
           * Conveniently offer the locale.
           */
          locale: props.ownProps.locale,
          /**
           * And the BCP47 normalise version.
           */
          bcp47Locale: normaliseBCP47Tag(props.ownProps.locale),
          /**
           * Localise a slug with insertions.
           * @param {string} resourceId Resource ID of the slug to localise.
           * @param {string} slug Default slug in case loading.
           * @param {Array<string> | Object: []} insertions Dynamic content for the slugs.
           * @returns {string} Localised slug.
           */
          localise: (resourceId: string, slug: string, insertions: [string] | Object = []): string => {
            if (!props[name].loading && !props[name].error) {
                           ^^^^^^^^^^ Checked here...
              for (let s of props[name].l10nSlugs) {
                                        ^^^^^^^^^^^ BAM!
                if (s.resourceId === resourceId) {
                  return insert(s.slug, insertions)
                }
              }
            }
            return insert(slug, insertions)
          },
          /**
           * Locale aware ordinals (e.g. 1st, ２番目)
           * @param {Number} ord The numerical ord to convert.
           * @returns {string} The locale-specific ordinal
           */
          ord2str: (ord: Number): string => props.ownProps.l10nShared(`${ord}ord`),
          /**
           * Get whether or not the current locale arranges the name Last, First.
           * @returns {boolean} True if the locale requires a Last, First name arrangement.
           */
          nameLastFirst: (): boolean => NameLastFirstLocales.includes(props.ownProps.locale),

          /**
           * Gets teh minimum number of characters allowed in the locale's name part.
           * @returns {number} The minimum number of characters in the current locale.
           */
          minCharsInNamePart: (): number => MinCharsInNamePart[props.ownProps.locale]
        }
      })
    }
  )

[malexandre]

Yeah, got the same error when trying to pass my company project to the last version, was previously in 1.4.16.

[Panoplos]

Is anyone looking into this? This is a serious bug that is killing quite a bit of my code, now.

[javascriptlove]

Can confirm this happens now after i updated today to apollo-client@2.0.1 and react-apollo@2.0.1

UPD:
some investigation/debugging led to this line in apollo-client package, giving null in the result,

https://github.com/apollographql/apollo-client/blob/f172ee6b37ab66d627b317d9b9f6ac1b8a739e00/packages/apollo-client/src/core/QueryManager.ts#L418

[jbaxleyiii]

@adamdonahue I'll take a look at this! Still working through issues after launch + took a week off last week! Thanks all for the issue report!

[javascriptlove]

Btw, i've resolved that on my side by setting fetchPolicy to cache-and-network, no more errors after that. So seems like the error is there only with network-only

[Panoplos]

@javascriptlove Actually, the issue exists with the default setting, too.

[moimael]

Any workaround that doesn't require adding a check on data for all loading queries ?

[peggyrayzis]

@adamdonahue Can you please provide a stripped down reproduction for us to test? I've tried to reproduce with our test app Githunt, but haven't been able to.

[malexandre]

I just tested with the 1.0.3 of apollo-client, and everything's work for me. Thanks a lot @jbaxleyiii.

[jbaxleyiii]

This has been confirmed as fixed with 1.0.3 in apollo-client! Thank you all for the reporting and helping to diagnose and fix this one!

[Panoplos]

Confirmed fixed in 2.0.1.

[j4mesjung]

EDIT:
Fixed on my end by just adding an id to every query level. However, still unsure why some id's returned the data but some did not...might have bad data on my end. Will continue to debug.

hi @jbaxleyiii, @peggyrayzis i am using graphcool service to host my data and all my queries work in their playground when I pass in the given ids. However, on the client side, some queries will correctly return the data and some will not return any data even if loading: false. I am on apollo-client 2.0.4

after some digging around, the data is coming in correctly into newData.results. However, isMissing resolves to true from this line isMissing = !newData.complete ? !newData.complete : false; because newData.complete comes in as false. This then ultimately resolves into this line that then takes the data from lastResult which is undefined and then resultFromStore.data returns undefined. Is there something wrong in my query that makes complete resolve to false? Not exactly sure what is happening here and would like some input if possible. Thanks!

[crokobit]

still have this issue with version '2.0.4' here 😢 . Sometimes it will work with safari but it constantly failed with chrome.

[j4mesjung]

@crokobit what do you mean by working in safari and failing in chrome? Are you talking about the data.loading: false but not seeing the expected data?

[shoooe]

I'm on 2.0.4 and the render function on a component is called 3 times, 2 of which have loading = false and data = null and the last one has the data.

What are those extra 2 renderers for?

[crokobit]

@j4mesjung yes~

[ssahni]

@jbaxleyiii @peggyrayzis This issue still occurs for me.

I am using react native and

• apollo-cache-inmemory: "^1.1.4"
• apollo-client: "^2.0.4"
• apollo-link-http: "^1.3.2"
• react-apollo: "^2.0.4"

Interestingly enough, the issue only arises when I introduce 'id' as a field in my query. If I do not specify 'id' in my query, then everything works as expected.

Render flow goes like this:

1. loading: true, no data
2. loading: false, data is available and good
3. loading: false, no data

Hope this helps!

[denkristoffer]

I'm seeing this too. If it helps, I know the data is already in the store and the request returns the correct data. It seems to happen when I render multiple components with queries at the same time?

• "apollo-client": "2.1.0"
• "react-apollo": "2.0.4"

[xcv58]

@denkristoffer do you have any reproduce repo? I can't reproduce this in my branch: https://github.com/xcv58/react-apollo-error-template/tree/2591adeeb9401fb90dcb28ed84c44d53ed58285a

[pencilcheck]

I have this issue as well, it is a very simple query but it just never return any data when loading is false and error is undefined.

"apollo-client": "2.0.4"
"react-apollo": "2.0.4"

However it returns very quickly when using graphiql

------------------ update ---------------------

Fixed it by adding id to every type in the query, like literally every type mentioned in affected query, otherwise it will not work...

[jdachtera]

I have the same problem after running a mutation which returns updated data.

[felixk42]

Can confirm I am having the same problem, used to work when id is attached to every queries, but now it doesn't. Seems to be triggered by a mutation that adds something.

[w9]

I have the same problem as well. (apollo-client@2.2.5)

This is a serious bug and this issue should be re-opened.

[hwillson]

@valoricDe Setting returnPartialData to true is the solution for this until the next major release of Apollo Client. After that, it will become the default.

[amannn]

@hwillson Thanks for the update on this issue!

Setting returnPartialData to true is the solution for this until the next major release of Apollo Client. After that, it will become the default.

Does that mean that in the next major release, in the example from the changelog, the component which uses GET_MEMBER_WITH_PLANS would resolve immediately with some properties missing by default?

If so, that sounds dangerous to me. If the second component is implemented to expect all properties to be available, it would work if it is implemented first. As soon as you add a component that requests less fields, the previous component could break.

Also: Is returning partial data really the fix to the problem described at the top of the issue? To me, a good default would be that loading becomes false as soon as all necessary data for a given query is fetched and that data can be provided to the component – no matter if another component uses a similar query. Handling partial data should be opt-in IMO, as it requires additional null checks, even for properties which are non-nullable in the schema.

Or am I missing something?

[proteus-aholt]

I don't see how returnPartialData has anything to do with the original bug. The issue here wasn't that we had extra web requests or anything that returnPartialData addresses. The issue here was (stolen from one of the original comments on this issue):

Render flow goes like this:

loading: true, no data
loading: false, data is available and good
loading: false, no data
Hope this helps!

from your changelog:

Apollo Client will not re-use the partial data that was cached from the first query, when it preps and displays the second component. 
It can't find a cache hit for the full second query, so it fires the full query over the network.

With this release, if you set a returnPartialData prop to true on the second component, 
the data available to that component will be automatically pre-loaded with the parts of the query that can be found in the cache, 
before the full query is fired over the network. This means you can do things like showing partial data in your components, 
while the rest of the data is being loaded over the network.

Sorry, but not gonna help for this bug. If anything this feature will just make this bug harder to reproduce. It is a band-aid over the real problem.

Please, if I am completely off-base, let me know.

[hwillson]

Would someone here be able to provide a small runnable reproduction that clearly demonstrates this issue? Talking around a concrete example of the problem will definitely help.

[amannn]

I was able to reproduce the issue, but the use case is a bit special. In my case it was related to how cache identifiers are generated. The example is a bit contrived, but maybe it helps to debug the issue.

Have a look at this code sandbox: https://codesandbox.io/s/apollo-error-reproduction-scrcx.

One of the query components always renders an empty object. If you remove one, the other one always succeeds.

If you look at the cache, it becomes clear why this fails:

{
  "Article:5d010e4e0bcb900018dd227b": {
    "id": "5d010e4e0bcb900018dd227b",
    "author": {
      "type": "id",
      "generated": false,
      "id": "Author:Holden Luntz Gallery",
      "typename": "Author"
    },
    "__typename": "Article",
    "href": "/article/holden-luntz-gallery-chapter-30-dialogues-great-photographers"
  },
  "Author:57a4ab99b202a366110001a9": {
    "id": "57a4ab99b202a366110001a9",
    "profile_handle": null,
    "__typename": "Author"
  },
  "ROOT_QUERY": {
    "articles({\"sort\":\"PUBLISHED_AT_ASC\"})": [
      {
        "type": "id",
        "generated": false,
        "id": "Article:5d010e4e0bcb900018dd227b",
        "typename": "Article"
      },
      // ...
    ],
    "article({\"id\":\"5d010e4e0bcb900018dd227b\"})": {
      "type": "id",
      "generated": false,
      "id": "Article:5d010e4e0bcb900018dd227b",
      "typename": "Article"
    }
  },
  "Author:Holden Luntz Gallery": {
    "id": "57a4ab99b202a366110001a9",
    "name": "Holden Luntz Gallery",
    "__typename": "Author"
  }
}

The entry with the identifier Author:57a4ab99b202a366110001a9 is no longer referenced in the cache and therefore the component that needs the data from this entry fails. I'm not sure though what the ideal solution would be as this is due to the normalization.

If you change the returnPartialData at the top, both components render, but one is missing data.

I had this bug a few times in a project where cache identifiers might be different based on what data is fetched. I guess my use should at least cause Apollo to throw with a helpful error message if this is a use case that isn't supported.

I have to say this is a special use case. Maybe someone else has a better example? The comments above might also be interesting.

[kgstew]

I found a simple example that may help illustrate the issue.

data will come back as an empty object if trying to fetch a field using the @client directive for a field that does not yet exist in the cache or have its own client resolver. There are no errors just an empty data object.

Removing the directive and trying to fetch a field that does not exist on the server does not cause the same issue however and the query will return the fields that do exist, ignoring the missing field.

The example is here.
https://codesandbox.io/embed/github/kgstew/react-apollo-bug-testing/tree/testing_client_directive/

[EternalVigil]

I've been experiencing a very similar issue when creating a React application with hooks. I have one component nested inside the other and each component has an independent query associated with it; it seems to resolve the outside component but returns an empty object for the inner component. I've test each component as a stand-alone and they both resolve fine when it's just the single query. Any ideas?

[amannn]

@EternalVigil can you create a reduced CodeSandebox example?

@hwillson can we please re-open this issue? It doesn't seem to me that this is solved.

[txbrown]

I am experiencing the same issue as well. I have a Dropdown component in the middle of the render of my component, some data has to be fetched for the dropdown options. after selecting an option, the query reads from the cache but the value of the field inside data is undefined.

[Oliver-ke]

I'm having the same issue, everything worked fine not until I added routing with react-router-dom and boom everything crashes, queries are only made on the first render, and once props changes query now returns data as empty object {}

[shyamzenefits]

Facing a similar issue . Able to see the error message in the apollo-link-error . But error from the Query components render props returns undefined . This is my response from the server .

{
  "data": null,
  "errors": [
    {
      "isNetworkError": true,
      "status": 401,
      "statusText": "UNAUTHORIZED",
      "data": "Please login"
    }
  ]
}

"react-apollo": "3.0.1",
"apollo-cache-inmemory": "1.6.3",
"apollo-client": "2.6.4",
"apollo-link": "1.2.12",
"apollo-link-batch-http": "^1.2.12",
"apollo-link-context": "1.0.18",
"apollo-link-error": "1.1.11",
"apollo-link-schema": "1.2.3",

[dylanwulf]

@shyamzenefits have you tried upgrading react-apollo? There was an issue with error disappearing which was fixed in v3.1.0

[shyamzenefits]

@dylanwulf Thanks for the swift response . Will try upgrading 👍

[shyamzenefits]

@dylanwulf Tried upgrading the apollo packages to v3.1.0 , but still facing the same issue . Any Suggestions ?

[dylanwulf]

@shyamzenefits Try upgrading to the latest available version (I think it's 3.1.3 right now). If that doesn't help, create a runnable reproduction (possibly with codesandbox) and post it in a new issue.

[japrogramer]

I have the same issue, in react data is always undefined despite receiving data from the server .. without the Announcement fragment data works but with the fragment for announcement data is undefined.

I tried it with the Panel fragment only and that results in data not being undefined
but with only the Announcement fragment than the data is undefined.
This is a very strange bug.

happens both while testing in localhost and in the server after deployment.

I do get this warning WARNING: heuristic fragment matching going on! index.js:1437
But no errors on the error

It links to this https://www.apollographql.com/docs/react/advanced/fragments.html#fragment-matcher
but that link is broken

Ninja Edit
Fixed with https://medium.com/commutatus/whats-going-on-with-the-heuristic-fragment-matcher-in-graphql-apollo-client-e721075e92be
but errors could be better.

"react-apollo": "^3.1.3",
"apollo-boost": "^0.4.4",
"apollo-link-ws": "^1.0.14",
"apollo-upload-client": "^11.0.0",

      <Query
        query={TimelineQuery}
        variables={{ page: page}}
        fetchPolicy={'network-only'} // skip the cache
      >
        {({ loading, error, data, refetch }) => {
          if (loading || !data) return <Linear />;
          console.log(loading, error, data, refetch)
          if (data == null) return <Linear />;
          return (
            <React.Fragment>
              <Sauce data={data}/>
            </React.Fragment>
          );
        }}
      </Query>

query TimeLine($page: Int) {
  currentTimeline(page: $page, perpage: 10) {
    pageInfo {
      Count
      CurrentPage
      NumPages
      hasNext
      hasPrevious
      hasOtherPages
      nextPageNumber
      previousPageNumber
      startIndex
      endIndex
      __typename
    }
    edges {
      node {
        subject {
          ...AnnouncementsInfo
          ... on PanelType {
            id
            hidden
            createdAt
            zipCode
            likesCount
            liked
            followsCount
            followed
            group {
              name
              id
              __typename
            }
            categories {
              edges {
                node {
                  id
                  category
                  __typename
                }
                __typename
              }
              __typename
            }
            comments {
              id
              createdAt
              liked
              likesCount
              thanked
              thanksCount
              attachments {
                attachment
                previewSm
                previewMd
                __typename
              }
              
              __typename
            }
            __typename
          }
          __typename
        }
        __typename
      }
      __typename
    }
    __typename
  }
}

fragment AnnouncementsInfo on AnnouncementType {
  
  categories {
    edges {
      node {
        id
        category
        __typename
      }
      __typename
    }
    __typename
  }
  attachments {
    attachment
    previewSm
    previewMd
    __typename
  }
  group {
    name
    id
    __typename
  }
  genComments {
    ...genComments
    __typename
  }
  createdAt
  modifiedAt
  hidden
  zipCode
  title
  id
  likesCount
  liked
  __typename
}

fragment genComments on GenCommentsType {
  id
  createdAt
  liked
  likesCount
  thanked
  thanksCount
  attachments {
    attachment
    previewSm
    previewMd
    __typename
  }
  author {
    id
    username
    fullName
    institution
    position
    profilePicSm
    __typename
  }
  __typename
}

{
  "data": {
    "currentTimeline": {
      "pageInfo": {
        "Count": 261,
        "CurrentPage": 1,
        "NumPages": 27,
        "hasNext": true,
        "hasPrevious": false,
        "hasOtherPages": true,
        "nextPageNumber": 2,
        "previousPageNumber": null,
        "startIndex": 1,
        "endIndex": 10,
        "__typename": "PaginatorInfo"
      },
      "edges": [
        {
          "node": {
            "subject": {
              "id": "UGFuZWxUeXBlOjI1NQ==",
              "hidden": false,
              "createdAt": "2019-11-14 11:19:52",
              "zipCode": "77098",
              "likesCount": 0,
              "liked": false,
              "followsCount": 0,
              "followed": false,
              "group": null,
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjQ5NQ==",
                      "category": "Mental health",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "comments": [],
              "__typename": "PanelType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        },
        {
          "node": {
            "subject": {
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjMxNA==",
                      "category": "General Community",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "attachments": [],
              "group": {
                "name": "Coco",
                "id": "R3JvdXBUeXBlOjY=",
                "__typename": "GroupType"
              },
              "genComments": [],
              "createdAt": "2019-11-06 18:24:50",
              "modifiedAt": "2019-11-06 18:24:50",
              "hidden": false,
              "zipCode": "Announcements",
              "title": "Testing general",
              "id": "QW5ub3VuY2VtZW50VHlwZToyMQ==",
              "likesCount": 0,
              "liked": false,
              "__typename": "AnnouncementType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        },
        {
          "node": {
            "subject": {
              "id": "UGFuZWxUeXBlOjI1NA==",
              "hidden": false,
              "createdAt": "2019-11-14 10:58:58",
              "zipCode": "Salado",
              "likesCount": 0,
              "liked": false,
              "followsCount": 0,
              "followed": false,
              "group": null,
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjk0Mw==",
                      "category": "sa",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "comments": [],
              "__typename": "PanelType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        },
        {
          "node": {
            "subject": {
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjY5MQ==",
                      "category": "ALF",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "attachments": [],
              "group": null,
              "genComments": [
                {
                  "id": "R2VuQ29tbWVudHNUeXBlOjE=",
                  "createdAt": "2019-11-06 18:01:42",
                  "liked": true,
                  "likesCount": 1,
                  "thanked": true,
                  "thanksCount": 1,
                  "attachments": [],
                  "author": {
                    "id": "VXNlclR5cGU6ODA=",
                    "username": "KratosMars",
                    "fullName": "kratos Mars",
                    "institution": "Programming",
                    "position": "Dev",
                    "profilePicSm": "/media/profile_pictures/User_80/1a9ae3c8-0033-4c6f-b7d8-db574e8a100a.jpeg",
                    "__typename": "UserType"
                  },
                  "__typename": "GenCommentsType"
                }
              ],
              "createdAt": "2019-08-29 19:20:41",
              "modifiedAt": "2019-08-29 19:20:41",
              "hidden": false,
              "zipCode": "some street address",
              "title": "direct link Announcements",
              "id": "QW5ub3VuY2VtZW50VHlwZToyMA==",
              "likesCount": 0,
              "liked": false,
              "__typename": "AnnouncementType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        },
        {
          "node": {
            "subject": {
              "id": "UGFuZWxUeXBlOjI1Mw==",
              "hidden": false,
              "createdAt": "2019-11-06 14:34:44",
              "zipCode": "Baytown",
              "likesCount": 0,
              "liked": false,
              "followsCount": 0,
              "followed": false,
              "group": null,
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjkxNw==",
                      "category": "mental health, depression, ptsd",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "comments": [
                {
                  "id": "Q29tbWVudHNUeXBlOjc1MQ==",
                  "createdAt": "2019-11-13 14:11:40",
                  "liked": false,
                  "likesCount": 0,
                  "thanked": false,
                  "thanksCount": 0,
                  "attachments": [],
                  "__typename": "CommentsType"
                }
              ],
              "__typename": "PanelType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        },
        {
          "node": {
            "subject": {
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjkwNg==",
                      "category": "test",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "attachments": [],
              "group": {
                "name": "testing",
                "id": "R3JvdXBUeXBlOjE=",
                "__typename": "GroupType"
              },
              "genComments": [],
              "createdAt": "2019-06-26 20:41:00",
              "modifiedAt": "2019-06-26 20:41:00",
              "hidden": false,
              "zipCode": "street of tests",
              "title": "Testing 2 ann 4 testing g",
              "id": "QW5ub3VuY2VtZW50VHlwZToxOQ==",
              "likesCount": 1,
              "liked": true,
              "__typename": "AnnouncementType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        },
        {
          "node": {
            "subject": {
              "id": "UGFuZWxUeXBlOjI1Mg==",
              "hidden": false,
              "createdAt": "2019-11-04 22:17:32",
              "zipCode": "Baytown",
              "likesCount": 0,
              "liked": false,
              "followsCount": 0,
              "followed": false,
              "group": null,
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjkxNw==",
                      "category": "mental health, depression, ptsd",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "comments": [],
              "__typename": "PanelType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        },
        {
          "node": {
            "subject": {
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjkwNg==",
                      "category": "test",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "attachments": [],
              "group": {
                "name": "testing",
                "id": "R3JvdXBUeXBlOjE=",
                "__typename": "GroupType"
              },
              "genComments": [],
              "createdAt": "2019-06-26 20:33:47",
              "modifiedAt": "2019-06-26 20:38:30",
              "hidden": false,
              "zipCode": "Testing street",
              "title": "testing group announcement",
              "id": "QW5ub3VuY2VtZW50VHlwZToxOA==",
              "likesCount": 0,
              "liked": false,
              "__typename": "AnnouncementType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        },
        {
          "node": {
            "subject": {
              "id": "UGFuZWxUeXBlOjI1MQ==",
              "hidden": false,
              "createdAt": "2019-11-01 14:19:29",
              "zipCode": "Baytown",
              "likesCount": 0,
              "liked": false,
              "followsCount": 0,
              "followed": false,
              "group": null,
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjkxNw==",
                      "category": "mental health, depression, ptsd",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "comments": [],
              "__typename": "PanelType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        },
        {
          "node": {
            "subject": {
              "categories": {
                "edges": [
                  {
                    "node": {
                      "id": "Q2F0ZWdvcnlUeXBlOjM3Mg==",
                      "category": "Advocacy",
                      "__typename": "CategoryType"
                    },
                    "__typename": "CategoryTypeEdge"
                  }
                ],
                "__typename": "CategoryTypeConnection"
              },
              "attachments": [
                {
                  "attachment": "/media/files/Announcement_17/bfed603d-5ade-420d-aab9-4a30b6a7512c.png",
                  "previewSm": "/media/files/Announcement_17/3df7f057-525d-440d-811c-15b4546c1f36.jpeg",
                  "previewMd": "/media/files/Announcement_17/a1507d80-79b0-4fd6-9755-fe1467af70e8.jpeg",
                  "__typename": "GenUploadType"
                }
              ],
              "group": null,
              "genComments": [],
              "createdAt": "2018-12-17 15:40:38",
              "modifiedAt": "2018-12-17 15:40:38",
              "hidden": false,
              "zipCode": "77433",
              "title": "test",
              "id": "QW5ub3VuY2VtZW50VHlwZToxNw==",
              "likesCount": 3,
              "liked": true,
              "__typename": "AnnouncementType"
            },
            "__typename": "ActivityType"
          },
          "__typename": "TimelinePQEdge"
        }
      ],
      "__typename": "TimelinePQConnection"
    }
  }
}

[vjsingh]

I just tried querying a list of fields with an 'id' param by mistake. Instead of getting an error I just got no data.

[jcace]

Same issue here, using apollo-boost 0.4.7 and @apollo/react-hooks 3.1.3. Basically, my app will end up with loading: false, error: undefined, data: undefined. Has this really not been fixed yet?

[amannn]

Can we reopen this issue? I saw this issue in two apps recently. I couldn't reproduce the bug so far but it's definitely still happening with the latest versions.

[schonfeld]

FWIW, I've experienced this issue and tracked it down to my query asking for a client schema local field that was no longer available. Removing the reference to that local field fixed the issue.

For example, I'd have a query such as this:

{
query Thread() {
  thread {
    messages {
      context {
        ... on Event {
          id
          state
          isPast @client
        }
      }
    }
  }
}

That isPast @client was recently removed from our client schema. Once I removed that field from the request, my useQuery calls started coming back with data, without needing to make use of returnPartialData.

Hope this helps!

[gamsterx]

I just stumbled upon the same issue. I can confirm that it only appears with network-only. I'm using the angular client so maybe this is not only react-apollo related?

In my query the roles array objects are undefined event though the response from the server contains the individual role objects...

 query getAreaById($id: uuid!) {
      area: areas_by_pk(id: $id) {
        id
        name
        roles {
          role {     // <== this object in the roles array is undefined
            id
            type
          }
        }
      }
    }

[KyleLee95]

Seems like this issue is being revived so I thought I would chime in as well.

Context:
Using Apollo-Client + react-apollo to connect to Shopify's Storefront API

Versions:
react-apollo: 3.1.5
apollo-client: 2.6.8

What I'm querying:

shop {
  name
  description
  products(first: 20) {
    pageInfo {
      hasNextPage
      hasPreviousPage
    }
    edges {
      node {
        id
        title
        options {
          id
          name
          values
        }
        variants(first: 250) {
          pageInfo {
            hasNextPage
            hasPreviousPage
          }
          edges {
            node {
              id
              title
              selectedOptions {
                name
                value
              }
              image {
                src
              }
              price
            }
          }
        }
        images(first: 250) {
          pageInfo {
            hasNextPage
            hasPreviousPage
          }
          edges {
            node {
              src
            }
          }
        }
      }
    }
  }
}

So far I've been able to get my data to render by doing this:

   <Query query={test}>
          {(res, loading, error) => {
            if (loading || !res.data) return 'loading...'
            if (error) return `${error}`
            return <React.Fragment>{res.data.shop.name}</React.Fragment>
          }}
    </Query>

Handling loading and !res.data the same way (since data is undefined by default). However, this is probably not the best way to handle this since res.data could truly be returning undefined.

[joselrodrigues]

Hi, i had same issue.
Context:
Using Apollo-Client + react-apollo to connect to django-graphene API.

I try to get jwt token from my back with:

const LOGIN = gql`
      mutation TokenAuth($username: String!, $password: String!) {
        tokenAuth(username: $username, password: $password) {
            token
            payload
            refreshExpiresIn
         }
      }
    `;

const [updateLogin, { loading, error }] = useMutation(LOGIN);

What i did to solve my problem was use then:

updateLogin({ variables: { username:"admin",  password:"admin"}}).then((data) => {
       console.log(data)
 })

it work for me every time.

[kierangillen]

Confirmed that adding id for every applicable field will fix this issue.

[art1373]

my query{
   users {
     data {
       name
       email
     }
   }
 }

no ID or anything. on react native version 61.5 on ios there is no problem, but on Android, although the URI is https nothing is happening loading becomes true and no error or data.

[art1373]

my query{
   users {
     data {
       name
       email
     }
   }
 }

no ID or anything. on react native version 61.5 on ios there is no problem, but on Android, although the URI is https nothing is happening loading becomes true and no error or data.

The problem was with t android emulator I switched to a real device and the query came back fine with data