Problem/Motivation
We have a Views page with 1543 results that works fine on our Acquia Cloud Classic production server. When our development servers were migrated to Cloud Next, the one page failed. When the acquia_purge module is uninstalled, the page works fine. When the results are limited to 1100, the page works fine. Changing the Views caching to time-based or disabled doesn't help.
This is a blocker for us to migrate our production server to Cloud Next.
And no, the client won't allow the number of results to be limited.
Steps to reproduce
Proposed resolution
Provide an EventSubscriber that checks if the number of cache tags is too large.
If it is, automatically reduce the tags to a level that will not cause a 503 error. Probably with an algorithm to drop file:*, media:* tags first and then reduce the node:tags. Or maybe just replace them all with entity_lists.
Log an error in Watchdog about this.
Result will be a not so efficiently cached page but at least no random 503's because the cache tag list got too large.
Remaining tasks
Make Acquia care enough about it's customers to do this.
Comments
Comment #2
keithdoyle9 commentedHas this ever been resolved? We're running into the same error.
Comment #3
papagrande@keithdoyle9, this ended up being a problem with too many cache tags on that client's page. Oddly, Cloud Next was worse than Cloud Classic when using the acquia_purge module.
I solved it by removing the individual cache tags with the
getCacheTagsToInvalidate()method on the custom entity. The entities are populated and displayed as a complete group so individual entity tags aren't needed.However, the problem remains in the module in that it shouldn't have a fatal error.
Comment #4
cgmonroe commentedAdded a possible work around to prevent this to the issue description.
I know this is possible because I have used onKernelResponse events to modify CacheableResponse response's CacheMetadata for other things.