I’m seeing intermittent ‘No routes matched location’ issues with a remix app.
Oddly, the site may load properly and then a few minutes later it fails to load assets associated with the page. In my logs I get an error message similar to the following:
May 15, 03:25:01 AM: ac38a4bf WARN No routes matched location "/build/entry.client-CPLICLLE.js"
After a few minutes, the site starts to load correctly again, without redeploying.
My site is at https://scripthungry.netlify.app or https://scripthungry.com.
I’ve noticed that it may be happening on my domain name and not through the netlify.app sub-domain. I’m managing my DNS through netlify name servers.
I’ve now noticed that when the site stops working correctly, it is requesting files with a different name:
e.g. When working: https://scripthungry.com/build/manifest-BE836987.js
When not working: https://scripthungry.com/build/manifest-8CD2A1DF.js
Am I looking at a caching issue?
If it helps, here are some x-nf-request-id’s for broken and working requests:
Full source code is also available at GitHub - mward-sudo/scripthungry-netlify if it assists.
Thinking of moving back to Vercel if I can’t get this working, especially as Vercel works proper with stal-while-revalidate caching headers.
Heya @mward-sudo and sorry to be slow to get back to you!
You nailed it in your diagnosis: you had several different versions of your landing page in our CDN’s cache. How did this happen? Your function, which handles the route for / on your site, seesm to return this
cache-control header (and did so as far back as the 14th, based on the age of the data in one node that I examined in depth)
Cache-Control: public, max-age=31536000, s-maxage=31536000
…which means that content would have (without my intervention, wherein I just deleted the entry from every CDN node manually), been stuck in cache for the next year as you’ve specified. This is obviously not what you want - so please, don’t do that again! Your function should return no
cache-control response header unless you genuinely want it cached for the length specified, regardless of any new deploys you make (a new production deploy will clear all cache…except for functions or other proxy routes that have told us to hold on to em via a
cache-control response header) - as long as you haven’t overridden our defaults as you did here).
Could you tell me if that was an intentional decision by you, and if so, what you were attempting to accomplish (and what you expected our system to do, given that directive?) This article explains why you should basically never need to adjust caching settings on our service:
Our team is working hard to improve our remix integration, by the way - keep an eye on our blog for a post about remix + edge functions in the very near future!
Team working on it gave me two pieces of most-relevant advice to you:
best way to start a remix project on Netlify today is to start from this template:
npx create-remix@latest --template netlify/remix-edge-template
in case you didn’t intentionally set that
cache-control header yourself, this thread has some details that may help you adjust it: How to set cache-control for dataRequests per route? · Discussion #2442 · remix-run/remix · GitHub
Thankyou for your reply.
cache-control header was deliberate. However, I had the expectation that the cache would be cleared upon deployment - clearly this was an incorrect understanding of the situation. I’ll be more more careful with setting the
I set the headers as I was experiencing slow loads due to server side fetch requests and wanted to improve the situation. I’ll do some reading, take a look at the Netlify remix template and have a look at how to set things up properly for fast responses.
Very much appreciated.
Out of interest, the starter template contains the following configuration in the
for = "/build/*"
"Cache-Control" = "public, max-age=31536000, s-maxage=31536000"
What effect does this have in comparison to setting the headers in the remix route files?
Hey there, @mward-sudo
Can you share the repo of the starter template you are using? This will help us look into the setup and answer your question. Thanks!
I’m using the netlify/remix-edge-template mentioned above.
I changed the
netlify.toml before deployment to:
for = "/build/*"
cache-control = '''
I did this to avoid the risk of incorrectly caching and causing the same problem I was having previously. However, if this setting only affects assets, which are uniquely named on each deployment, then it might be better that I use the original value as specified in my previous post.
Hey there, @mward-sudo
Thanks for your patience here. I want to assure you we haven’t forgotten about you! We have shared this with a team that works directly with this template and will follow up here when we have more information. If anything changed in the past seven days, please let us know.
I believe the headers set by the starter template in
netlify.toml work because those only apply to some static files that get generated during the build. Those files are hashed, so caching or not caching them would not make a huge difference.
But, when you added those headers inside your Remix stuff, I believe they also got applied to the serverless functions serving the content, and that’s what caused issues.
Brilliant, that is what I suspected.
Thank you very much for the assistance and information.