uiowa / uiowa

The base application on Acquia Cloud for the University of Iowa.
11 stars 9 forks source link

Event views cache is not being cleared and displays events from the previous day #6788

Closed pyrello closed 1 year ago

pyrello commented 1 year ago

Report from Scott:

I’m noticing something else that should be happening that is not. I’m sure we talked about this. We need the events of past days to disappear. I still see Sunday on this list and it should be gone so that the current day is at the top of that page.

I’m not sure if you did something just now, or it hadn’t updated yet and I was seeing an older version, but it looks like it’s now showing the correct day at the top of the page.

Proposed solution

pyrello commented 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.

pyrello commented 1 year ago

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.

pyrello commented 1 year ago

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.

briand44 commented 1 year ago

We noticed the job was using UTC so it has been updated to run at 6 UTC so it runs after midnight Central time.

joewhitsitt commented 1 year ago

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.

briand44 commented 1 year ago

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.

joewhitsitt commented 1 year ago

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.

briand44 commented 1 year ago

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

joewhitsitt commented 1 year ago

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.

briand44 commented 1 year ago

Checked at 5:30am today and the event was no longer showing

joewhitsitt commented 1 year ago

I had mentioned in standup that we could setup another test with the "day clearing" in mind if you want more confirmation before closing.

joewhitsitt commented 1 year ago

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