Closed pyrello closed 1 year ago
This appears to be an issue describing our problem: https://www.drupal.org/project/drupal/issues/2968485
This is a potential workraround: https://bkosborne.com/blog/keeping-a-view-of-upcoming-events-fresh-in-drupal-8/
The workaround described above is not totally straightforward. We have to add a new module, then implement some code to make use of the module, then add some code to cause our cache to be properly invalidated on a cron run. This is all doable, but isn't something that can be slapped together in a hurry. We are likely to experience the same issue with https://oniowa.uiowa.edu/events tomorrow and will need to manually clear cache again to fix it.
We should implement a fix for this at the event feature level rather than just for OnIowa. We are seeing this issue with their site because of the large volume of events they have listed, but it is likely to be an issue for any site that uses site events.
We are deciding to not address this immediately. Instead we have set up a scheduled job to run at 4:00 AM to rebuild cache on the OnIowa site. At whatever point we complete this work, we should remove the uiowa02
scheduled job.
We noticed the job was using UTC so it has been updated to run at 6 UTC so it runs after midnight Central time.
I looked into this a bit and based on https://github.com/uiowa/uiowa/issues/6788#issuecomment-1679663869 I think that varnish is also at play as the invalidation would bubble up to purge/acquia_purge/varnish where as a cr
without no other site activity would not. Perhaps by luck, varnish expired when only site cache was manually triggered before.
We have the time:hourly cache tag that we use for ui events. It could be used on these site events view pages and blocks. As noted in that blog post, it would be easier to implement with the views_custom_cache_tag module, but I think setting it in the pre_view
would also work.
Perhaps by luck, varnish expired when only site cache was manually triggered before.
Perhaps but we've manually cleared the cache for the last 8 days without clearing Varnish and it has solved the issue.
Perhaps not then. Nothing else stuck out when I inspected the scheduled job and comparing it with others. Can't actually tell if it is running. It and our other drush commands don't seem to write to the drush-logs correctly and I don't seem to see cache rebuild activity in splunk.
I created a test event on Admissions stage. The event is for today (9/5) from 1pm-2pm. As of now (3:53pm), the event is still showing https://admissions.stage.drupal.uiowa.edu/events
Bummer. Could this be related to the exposed (but hidden) day filter and that we need to wait for 9/6?
The test instructions on the fix PR for alerts required temporarily changing the filter from today to now.
Checked at 5:30am today and the event was no longer showing
I had mentioned in standup that we could setup another test with the "day clearing" in mind if you want more confirmation before closing.
From standup. We believe that the view in question is a daily filter so Brian's test results seem to confirm that the fix is working. Closing. We can reopen if we get unexpected results going forward
Report from Scott:
Proposed solution
uiowa02