gatsby-source-sanity icon indicating copy to clipboard operation
gatsby-source-sanity copied to clipboard

Clear cache required for resolveReferences to work after adding new object and document type

Open pertedgustaf opened this issue 3 years ago • 5 comments
trafficstars

  1. Create a new document type (newPage)
  2. Create a new object type with an array of references to the new document type (newObject.newPageReferences)
  3. Add the new object type to allowed types in a portable text area (oldPage.portableTextContent)
  4. Add some sample data
  5. Deploy GraphQL API
  6. Build gatsby site
  7. Query _rawPortableTextContent(resolveReferences: { maxDepth: 10 }) (in a page or via graphiql)

Actual result:

  • The reference to the new page type (each item in newPageReferences) returns null
  • If I clear Gatsby's cache and rebuild, resolveReferences starts working again, and newPageReferences will contain the properties of the linked page.
  • I get this behaviour on Gatsby Cloud as well

Expected result:

  • When building the site (full build), I expected that resolveReferences should result in the page properties being returned without a manual gatsby clean.

gatsby@^4.4.0 (4.4.0) gatsby-source-sanity@^7.3.2 (7.3.2)

pertedgustaf avatar Apr 11 '22 14:04 pertedgustaf

I believe we are also experiencing this issue which is requiring us to run a yarn clean as part of the build step. This is not ideal since it makes our build much longer.

neilorama avatar Apr 19 '22 15:04 neilorama

I've been looking into this exact issue too and have found the following within the sourcesNodes function of gatsby-node.ts within the plugin...

When there is no cache, ALL documents and objects are downloaded into cache with their IDs.

Once a cache has been generated, the second time around a separate procedure is run where documents are "touched" using action.touchNode this is to prevent Gatsby removing the item from the cache. However, this process gets documents only and therefore removes object references where isDocument is false, as they don't get "touched" for Gatsby to keep them.

Therefore the start up procedure and run from cache procedures are caching two different datasets, with the latter deleting much more from cache than it should, causing the references to break.

nicktaylor avatar May 27 '22 13:05 nicktaylor

Thanks for highlighting!

evenwestvang avatar Jun 02 '22 08:06 evenwestvang

Could this issue be the root of https://www.reddit.com/r/gatsbyjs/comments/uw8jq7/cache_issue_in_netlify/ as well?

raae avatar Jun 02 '22 11:06 raae

Thank you! We're looking into it.

evenwestvang avatar Jun 02 '22 20:06 evenwestvang