Greetings 
I’ve had a couple of intermittent issues in the last few months and my typical work-around isn’t working anymore so I figured I’d post a thread! My site ID is f8ae2cd6-4da1-4c06-ac9a-275206f29605.
Essentially I’m seeing strange behavior where the Netlify CDN doesn’t seem to update with the latest version of my site’s files after a (successful) build, but only for my primary domain. So for data-points, my site’s build process runs fine when running via the Netlify builder (example deploy 6276c5d29f181530d582efa2) and publishes the files to the CDN seemingly fine: Site is live ✨ where the content is all available and functioning quite normally at the hashed-permalink domain (link) but the content fails to update correctly on the primary domain (lots of errors, Gatsby app totally fails).
Alternatively if I disconnect the site from the Github repository and instead build the site locally and deploy via netlify deploy --prod (example deploy 6276f3cf75651d555d7d33ba) I get similar results — it appears that even though the CDN ran the diff and requested specific files whose hashes changed, it has some kind of issues when uploading the files to the CDN.
In particular, my webpack-runtime.js is failing to update so a request to the site yields an old version of the webpack-runtime.js… which in turn references js/css files that no longer exist in this newer version of the site. Smells like a caching bug — either the CDN holding onto old files or possibly headers.
For context, I have gatsby-plugin-remove-fingerprints installed since it’s Netlify’s recommended behavior for static sites — don’t fingerprint your own files, let Netlify’s CDN handle caching on its own, no fingerprints required. (I believe the tl;dr: idea here is essentially that files that don’t change between builds won’t need to be re-downloaded by folks that browse the site before then after the new publish)
Additionally, I have gatsby-plugin-netlify running (v4.3.1, latest) and, while I have no _headers file of my own, this plugin generates a large one for my site.
Alright, I ended up solving this one myself while writing it out and digging further, but I’ll go ahead and post anyway and hope that my particular situation speaks to others, while asking for insight from the team behind gatsby-plugin-netlify (
)
Turns out you can’t mix gatsby-plugin-remove-fingerprints and gatsby-plugin-netlify. remove-fingerprints …removes all the fingerprints off Gatsby-generated files. So what would’ve been webpack-runtime-2bbb73d9f71c5f1e8581.js is instead just webpack-runtime.js while, on the other hand, gatsby-plugin-netlify generates a _headers file that explicitly sets very, very long cache header times for all Gatsby files… presumably because it expects your Gatsby site to generate fingerprinted files (like a normal Gatsby site does!). Combine the two and you have a caching problem: each deploy has files of the same names while the cache-header for the previous version still has lots of life left!
My pending question is just for some clarity of intention behind gatsby-plugin-netlify — I believe it’s still considered SOP by Netlify to not fingerprint files in a static-build so that Netlify’s own CDN cache headers can ‘smartly’ handle it all for you… was the idea to add overriding (long) cache headers to Gatsby site files since Gatsby does fingerprint files? E.g. either override with long headers or de-fingerprint the files (probably out of scope for gatsby-plugin-netlify) and the choice was made for the former? Just wanting to know 
Could be worth calling out in the repo README. This whole paragraph may also be better suited as an issue in that repo too, happy to move this question there.
–
Jon