oops, we didn't actually add it yet to FAST_DEV. Thanks for the reminder! PR #28447

Is the instructions in the body of the discussion more clear? Thanks for letting us know — we'll keep iterating on the instructions to make them more clear.

This was much clearer:

module.exports = {
  flags: {
    PRESERVE_FILE_DOWNLOAD_CACHE: true,
    PRESERVE_WEBPACK_CACHE: true
  },
  plugins: [...]
}

Can you add a screenshot of the error?

Apologies, please delete!

Same for me. I updated and the behavior started. Unfortunatelty I can seem to fix it temporarily by setting the flags to false or did I miss any?

Edit: Added PARALLEL_SOURCING to the mix without success on gatsby-cli@latest.

Downgrading gatsby-cli to 2.15.1 resolved the issue, testing 2.16.1 reintroduced it.

I have also experienced this issue on Gatsby v 2.31.0

So I was testing our your PR against an image from unsplash and it still wasn't working. I looked into it more and realized that we've only ever added support for etag caching — one of multiple options a server might use. So even with this, there'll be plenty of images which won't get cached correctly.

Looking around, I think we should switch to using https://www.npmjs.com/package/make-fetch-happen as it promises us — "Built-in request caching following full HTTP caching rules (Cache-Control, ETag, 304s, cache fallback on error, etc)."

heh actually got has caching support we can use so need to switch — https://github.com/sindresorhus/got#cache-1

I tested it quickly against the unsplash URLs and it works as expected

I'll work on a PR to add caching support next week

hmmm actually (another yet again) — https://github.com/kornelski/http-cache-semantics is what we want. The "Got" cache means that we'd need to read & write to our cache each time — http-cache-semantics is lower-level so would let us simply look at the previous response headers and often just say we need to do nothing (e.g. the server responded with cache-control: max-age=604800).

So this would work like our current system but have much more robust support for different caching setups. I might just post an issue though as I think the etag works with our main integrations e.g. Drupal/WordPress/Contentful/etc as all these set etag

One plus to changing is right now we do revalidate every time where w/ the above, we often wouldn't — which would save a lot of http requests.

Don't check it in — just setup your CI to preserve and restore the .cache and public folders in between builds.

My current cache workaround:

  config.cache = {
    type: 'filesystem',
    buildDependencies: {
      config: [
        __filename,
        path.resolve(process.cwd(), 'package.json'),
        path.resolve(process.cwd(), 'tsconfig.json'),
        ...store
          .getState()
          .flattenedPlugins.filter((plugin: any) =>
            plugin.nodeAPIs.includes(`onCreateWebpackConfig`)
          )
          .map((plugin: any) => {
            const pluginPath = path.join(plugin.resolve, `gatsby-node.js`);
            const pluginPathTs = path.join(plugin.resolve, `gatsby-node.ts`);
            let foundPluginPath;

            try {
              fs.readFileSync(pluginPath);
              foundPluginPath = pluginPath;
              return foundPluginPath;
            } catch (error: any) {
              reporter.info(`[${pluginOptions.pluginName}] could not find file: ${pluginPath}`);
            }

            try {
              reporter.info(`[${pluginOptions.pluginName}] trying file in ts: ${pluginPathTs}`);
              fs.readFileSync(pluginPathTs);
              reporter.info(`[${pluginOptions.pluginName}] found file: ${pluginPathTs}`);
              foundPluginPath = pluginPathTs;
            } catch (error: any) {
              reporter.info(`[${pluginOptions.pluginName}] could not find file: ${pluginPathTs}`);
            }
            return foundPluginPath;
          }),
      ],
    },
  };

Output:

info [gastby-plugin-core] could not find file: /Users/phil/Code/newrade-core/packages/core-gatsby-config/src/plugins/gatsby-plugin-core/gatsby-node.js
info [gastby-plugin-core] trying file in ts: /Users/phil/Code/newrade-core/packages/core-gatsby-config/src/plugins/gatsby-plugin-core/gatsby-node.ts
info [gastby-plugin-core] found file: /Users/phil/Code/newrade-core/packages/core-gatsby-config/src/plugins/gatsby-plugin-core/gatsby-node.ts
info [gastby-plugin-core] could not find file: /Users/phil/Code/newrade-core/packages/core-gatsby-config/src/plugins/gatsby-plugin-treat/gatsby-node.js
info [gastby-plugin-core] trying file in ts: /Users/phil/Code/newrade-core/packages/core-gatsby-config/src/plugins/gatsby-plugin-treat/gatsby-node.ts
info [gastby-plugin-core] found file: /Users/phil/Code/newrade-core/packages/core-gatsby-config/src/plugins/gatsby-plugin-treat/gatsby-node.ts
info [gastby-plugin-core] could not find file: /Users/phil/Code/newrade-core/packages/core-gatsby-config/src/plugins/gatsby-plugin-vanilla/gatsby-node.js
info [gastby-plugin-core] trying file in ts: /Users/phil/Code/newrade-core/packages/core-gatsby-config/src/plugins/gatsby-plugin-vanilla/gatsby-node.ts
info [gastby-plugin-core] found file: /Users/phil/Code/newrade-core/packages/core-gatsby-config/src/plugins/gatsby-plugin-vanilla/gatsby-node.ts

It replaces the cache entries for gatsby config files with the correct .ts versions

The above workaround works for v3.13.0, just make sure that you set the .cache prop and actions.replaceWebpackConfig(config); for every stage

Yes, it's an idea… I've also lost sooooooo… many time !
May be with a principle of cache container (with a name) to clear specific parts / usages of the cache.