Static cache not always invalidating entry when saved through control panel

[mgtcampbell]

Overview

I have seen some similar discussions and issues posted however have not come across any reliable fix for my issue.

The issue is that on a client site saving a change to an entry via the CMS does not always invalidate the static cache (half measure).

You can see the change in live preview, however it is not updated on the front end of the site. In the screenshot below note the button is present in the live preview but does not appear on the site after publishing the entry and refreshing the page.

The site is a mutlisite, though all on the one domain, so I am wondering if this has something to do with the issue. I have not done any additional configuration in my cache config files, as the specifics in the documentation for multisite caching specifically say they are for full cache strategy only, not half which I am using.

The problem has been around for a couple of months at least, and I have been updating statmic regularly but it keeps coming back.

Due to the ephemeral nature of updates (especially since it's the client handling this not me), it is very hard to troubleshoot.

They do occasionally send me specific examples I can reproduce like the ones above, but I do not then know how to dig into the cache storage itself to try and diagnose why a specific entry like that one is not being served up as the latest version.

Any tips on how to troubleshoot the invalidation/caching of an individual entry, especially in this setup (multisite, half measure static caching) would be greatly appreciated.

Site set up

Hosting: Vultr/Forge
Statamic Version: 3.3.65
Laravel Version: 9.48.0
Static caching strategy: half, driver => application
Laravel Cache Driver: file
Multisite: True

Other notes:

• No CDN caching is enabled
• using AWS hosting
• clearing the cache from the command line does appear to "fix" the issue for a specific entry

[edalzell]

Are you using redis for your queue?

[mgtcampbell]

My current ENV settings (confirmed via Tinker that they're pulling through):

CACHE_DRIVER=file
QUEUE_CONNECTION=sync

I did try Redis as the queue at one point and have a Redis queue still running on the server... should I try disabling that? I would assume it's not affecting this anymore since it's back to sync but open to anything at this stage.

[johncarter-]

Apologies for the tag @mgtcampbell — but did you manage to work out a fix for this, or are you waiting for the core team?

[mgtcampbell]

No worries @johncarter- - I'd be happy to help if I can...

For me most cache busting issues were resolved with the fix for using the full URL in the sites config vs just '/', as documented on other threads.

In regards to actually using the queue for it, I did not ever resolve this and just went back to using sync instead. I couldn't get it to work consistently but I also think it may have been down to the setup being on shared hosting and there being some crossed wires with queues from different sites with the same queue connection + name (not confirmed, just a hunch about my situation).

[johncarter-]

Thanks so much, mate. I've got the URLs set up properly but my redis queue might be causing some issues — I'll revert to sync for now and see if that gets it working.

[mgtcampbell]

No worries mate - good luck!