Issue on course page cache

[igobranco]

Bug Report

Expected behavior/code

Richie is caching the course page too much. It takes a couple of hours (max 1 day) to the page to be updated for the student. In reality tt takes the time that is configured on the CMS_CACHE_DURATIONS setting. Richie has 1 minute, Open Fun uses 1 day, and I've changed to 30 minutes on NAU homepage.

Actual Behavior

Use cases with that problem:

1. a course run date has passed and the run is now closed for enrollment

When the enrollment end date expires, the course page is not changed for the next minutes/hours page views. So the student view the enroll now button, but the button raises an error! The course is closed on the LMS. If we view the course page on authenticated mode, the course run is updated, but if we view the course page using an unauthenticated user we still view the old dates and the enroll now button. So at least for a couple of hours we received some tickets for some students that saw and tried to enroll on the run.

2. a course run date have been changed

If a course run is changed on the LMS, it is being synchronized using the Richie API. But that change is not visible right away because of the Django cache. The course page is updated for the authenticated Richie user, but for the unauthenticated Richie user is still viewing the old course page content.

Steps to Reproduce

1. Verify that CMS_CACHE_DURATIONS has value of 60 seconds or greather;
2. On a course with only one open run, change the enrollment end date on the minute at 0 seconds and publish the page;
3. Open an incognito browser tab and view the page, on the next minute it still show the old page content with that run open to enroll;
4. After that minute it will be updated and closed for enroll.

Possible Solutions

1. When a course run date is changed it should invalidate the page cache. Is there a programmatic way of invalidate the cache for a page?
2. When a course run date passes, like enrollment end date has finished, the cache should miss the page, and on the next request it should be generated / updated. Probably change the LimitBrowserCacheTTLHeaders class so it uses the minimum value of the current value and the first future date of the course runs.

[igobranco]

Today, during the meeting with @sampaccoud, this issue has been discussed. It was decided that it would better to populate the cache with a limited ttl per business logic, instead of using the PR #1665 code that limit the ttl only on the response header after getting the page on the cache.