(graphache) - Fix query traversal for previous null fields

[kitten]

Fix #768

Summary

This issue occurs when a previous selection determined a field to be null. A future selection that doesn't result in null is then forced to retrieved prevData, but isn't covering the null case.

This can happen with split selections on a single entity, e.g.

query Item {
  ...NullItem
  ...ValidItem
}

fragment NullItem {
  item {
    id
    invalid # Suppose this causes the item to become null, due to an invalid field
  }
}

fragment ValidItem {
  item {
    id
  }
}

• On the first traversal, the NullItem fragment hits invalid which causes Query.item to become null
• On the second traversal, the Validitem fragment hits id and tries to write it, but Query.item is already null

This can only happen with schema awareness most of the time.

Set of changes

• Handle prevData === null by switching most of its uses to a truthy rather than an undefined check.
• Fix case where prevData === null leads to further traversal

Outstanding edge cases

The read edge case can be seen in this PR's test case, when a traversal fails and returns undefined, then the second traversal doesn't set the affected field to null.

[changeset-bot]

🦋 Changeset is good to go

Latest commit: 70d5e2b

We got this.

This PR includes changesets to release 1 package

Name	Type
@urql/exchange-graphcache	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[kitten]

We can fix the write edge case probably by introducing prevData to writeField and checking whether a previously written field was null before committing it.

We can maybe fix the read edge case by introducing a mode on SelectionIterator somehow that pre-merges overlapping selection sets.

Edit: I believe the write case is sufficiently unlikely and a fix would simply make its behaviour a little more intuitive for a very high cost.

[wgolledge]

Nice 👍