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

useQuery returns neither data, nor an error when aliased fields are used with cache #7636

Open
pastelsky opened this issue Feb 1, 2021 · 0 comments
Labels
🔍 investigate Investigate further

Comments

@pastelsky
Copy link

pastelsky commented Feb 1, 2021

Consider a query like this which queries for compatibleProducts at two places —

query GetMarketplaceAppListingById {
  marketplaceApp(appId: 1215460) {

    ...Fragment1

    versions(first: 1) {
      edges {
        node {
          deployment {
            compatibleProducts {
              id
            }
          }
        }
      }
    }
  }
}

fragment Fragment1 on MarketplaceApp {
  cloudAppVersion: versions(first: 1 }) { 
    edges {
      node {
        deployment {
          compatibleProducts {
            name
          }
        }
      }
    }
  }
}

Intended outcome:

When using a cache-first (default) strategy, querying for the same field in multiple fragments containing aliased fields should return results as expected.

Data should be populated. If for some reason, apollo cannot handle caching, it is skipped, or at-least an error is thrown.

Actual outcome:

Both data and error are undefined, even after loading is finished.

There are three (independent) ways to work around this —

  1. Switch from a cache-first to network-only strategy.
  2. Don't use the cloudAppVersion alias
  3. Add an id in the part that queries for compatibleProducts in Fragment1 along with name

but having to use these would be unfortunate.

How to reproduce the issue:
https://codesandbox.io/s/apollo-graphql-cache-bug-xy97t?file=/src/index.js:0-1466

Versions
At-least 3.2.x and 3.3.x both have this issue.

@jcreighton jcreighton self-assigned this Mar 2, 2021
@brainkim brainkim self-assigned this Jun 22, 2021
@hwillson hwillson added the 🔍 investigate Investigate further label May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔍 investigate Investigate further
Projects
None yet
Development

No branches or pull requests

4 participants