After rebuilding a site, Netlify now fails to serve up the new version as before when opening the production deploy, instead returning a [HTTP/2 304 Not Modified] to the browser. Opening the preview results in the expected updated build. Has there perhaps been a recent sudden change in caching artifacts?
Hi, @TerjeNorderhaug. The deploys are locked for that site here:
As the branch
main is the production branch, that is locking the branch subdomain URL (
https://main--claritygpt.netlify.app/) to the locked version. That is what is preventing that URL from updating. If you unlock deploys or use the deploy id version of the URL (like the second link) the issue will be resolved.
If there are other questions, please let us know.
Thanks @luke. I understand that the site has to be unlocked to be automatically deployed. My workflow is to open the production deploy to verify it’s ready to be manually published as the production site. I continue to find that changes pushed to github are not reflected in the “production deploy”.
Seems like these developers are having a similar problem in that changes pushed to github are not showing up on netlify:
It turns out our issue was unrelated. Our situation was with a course assignment at my University. Our assignment wasn’t meant to work properly in Netlify yet, but the instructions never specified that, and my professor ended up having to tell me.
Sorry for the confusion. I really appreciate Netlify support being so responsive! I’ll let you know if our situation changes.
Hi, @TerjeNorderhaug. Again, everything at Netlify is working as designed. It may not be working in the way you expected but it is working correctly.
For example, the current published production deploy is this deploy below from April 27th:
The most recent deploy of that branch is this deploy:
My point is that the branch subdomain of
main--claritygpt.netlify.app is locked to that April 27th deploy because auto-publishing of that branch is locked.
We can get the checksums of the page to compare versions:
$ curl -s https://main--claritygpt.netlify.app/ | sha1sum cadb3350e905a8f1299aeef2468f5a237849dbe9 - $ curl -s https://644b159c0af42800084d1f24--claritygpt.netlify.app/ | sha1sum cadb3350e905a8f1299aeef2468f5a237849dbe9 - $ curl -s https://645030620cf1d21b851b191b--claritygpt.netlify.app/ | sha1sum bc0657e4a1203b6fb248429d4f319050f908fbc2 -
That proves that the April 27th version is version used because the production deploy is locked.
Does the https://645030620cf1d21b851b191b--claritygpt.netlify.app/ page show the updates? If so, then the updates are being pushed to Netlify. The reason they don’t show up for
main--claritygpt is because of the lock.
However, if you don’t see the changes at https://645030620cf1d21b851b191b--claritygpt.netlify.app/ either or if there are other questions about this, please let us know.
Here are my steps for clues to the origin of the problem:
- Commit and push to github.
- Wait for the deploy
645089edf4904f000893daffto complete building on netlify.
- Download the build using the image button to the right of the label
- Verify that the
index.htmlin the downloaded “zip with deployed files” is identical to the one pushed to github.
Open Production Deploybut the page source is the stale index.html.
curl -i [https://main--claritygpt.netlify.app/](https://main--claritygpt.netlify.app/`) returns the stale index.html with these headers:
HTTP/2 200 accept-ranges: bytes age: 49090 cache-control: public, max-age=0, must-revalidate content-type: text/html; charset=UTF-8 date: Tue, 02 May 2023 03:01:32 GMT etag: "5f218611fa909600972378eacd2d393b-ssl" server: Netlify strict-transport-security: max-age=31536000; includeSubDomains; preload x-nf-request-id: 01GZENB19FMM9Y64SS3XTEN2Z3 content-length: 1337
everything at Netlify is working as designed. It may not be working in the way you expected but it is working correctly.
My point is that the branch subdomain of
[main--claritygpt.netlify.app](http://main--claritygpt.netlify.app)is locked to that April 27th deploy because auto-publishing of that branch is locked.
It is unexpected that the branch subdomain can be locked, perhaps because I’m using it to preview the deploy. There is no indication it is locked in the UI, and no Option to enable auto-publishing.
Hi, @TerjeNorderhaug. Yes, the URL
https://main--claritygpt.netlify.app/ is locked to this deploy:
https://644b159c0af42800084d1f24--claritygpt.netlify.app/. Everything you are seeing is working exactly as it is intended. There is no bug and nothing mysterious is happening.
Because you have locked the production deploys, the branch subdomain URL for the production branch is also locked. This is expected.
Do you have a question about what you are seeing?
@luke To me, it’s not the case that “nothing mysterious is happening.” I find the way this work to be unexpected. Perhaps the UX team should get involved for a second take on the design?
Practical question: How can the branch subdomain be unlocked while keeping auto publishing disabled so the published production deploy remains locked? I would like to preview the latest deploy before it is published.
Hi @TerjeNorderhaug ,
Thanks for following up. It can’t be done. This is how locking deploys is supposed to work.
You need to use the deploy ID URL or Another option is to make a second site using the same repo and not lock deploys on that second site.