graybeal
commented
2 years ago @syphax-bouazzouni @jvendetti Sorry, I have a naive question as I was compiling our clear caching issues. As I haven't studied the code, please consider this a curiosity question, not a critique. (Read: A really short answer is fine if the question isn't helpful.)
Your question was
The problem is why the function invalidate_cache is doing an self.class.all(invalidate_cache: true) when doing a save or update.
I assume the reason for the function doing self.class.all(invalidate_cache) is because the self has been changed, and so the cache for self is no longer valid, and so we want that cache to be invalidated so that it is recached on the next request. In which case removing this call means the cache will in fact continue to represent old information, which is a problem. What am I missing?
Assuming we do want the cache to be invalidated when self has changed, the original call seems like an appropriate way to do it. In which case the problem should be stated as "there is a problem when invalidating the cache which may be preventing the invalidation from correctly taking place, so we need to troubleshoot the error and confirm that the cache is correctly invalidated" (presumably what the retrieval was trying to do).
syphax-bouazzouni
jvendetti
We had this issue https://github.com/agroportal/documentation/issues/190 at Agroportal
And it was caused by Timeout due to the function invalidate cache when adding or updating a submission, see the fullstack trace below
The problem
The problem is why the function invalidate_cache is doing an
self.class.all(invalidate_cache: true)when doing a save or update. In our case (at Agrportal) theself.class.all(invalidate_cache: true)for submissions take a lot of time than it causes a request time out.Our solution
Add the option to not call to
self.class.all(invalidate_cache: true)in the invalidate_cache