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

null data has been returned after fetch done with valid data when using nested local resolver #3370

Closed
3 tasks done
jet2jet opened this issue Sep 4, 2023 · 1 comment · Fixed by #3371
Closed
3 tasks done

Comments

@jet2jet
Copy link

jet2jet commented Sep 4, 2023

Describe the bug

When using nested local resolver (resolver not under root Query), returned data may be null even though data has been fetched correctly.

If I changed the line below:

https://github.com/urql-graphql/urql/blob/%40urql/exchange-graphcache%406.3.2/exchanges/graphcache/src/operations/query.ts#L612

-  } else if (!isOwnedData && prevData === null) {
+  } else if (isOwnedData && prevData === null) {

... it seems to work correctly.
# I saw that in commit 6031d91 skipNull was changed to isOwnedData, but in the only above line ! was added.

Reproduction

https://github.com/jet2jet/urql-local-resolver-test

  1. Run npm run start
  2. Open http://localhost:3000
  3. When Todo list is displayed, type Todo id to ID field and press Get
  4. Expect behavior: Todo detail data is retrieved and displayed
  5. Actual behavior: Todo is null... is displayed

Urql version

urql v4.0.5
@urql/exchange-graphcache v6.3.2

Validations

  • I can confirm that this is a bug report, and not a feature request, RFC, question, or discussion, for which GitHub Discussions should be used
  • Read the docs.
  • Follow our Code of Conduct
@kitten
Copy link
Member

kitten commented Sep 4, 2023

That's a really nice catch and a great diagnosis! I've confirmed that the line you mentioned contains a typo (which is more easily spotted when comparing it to resolveLink) and wrote a quick unit test next to the one that checks that resolveLink behaves correctly, to prevent this from regressing again. Cheers! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants