Delayed Subsection Due Date Updates in LMS After Studio Changes (Tutor v19.0.0)

I’m running a fresh installation of Open edX on an AWS EC2 instance using Tutor version 19.0.0 (Sumac release). I enabled the course_experience.relative_dates waffle flag via the admin panel to display assessment due dates in the LMS Dates tab. However, I’ve noticed that when I update a subsection’s assessment due date in Studio, the change does not immediately reflect in the LMS, specifically in the Course Outline and Dates tab.

Observed Behavior

Questions

  1. What could be causing this delay in reflecting subsection due date updates in the LMS?
  2. Is this likely a caching issue? If so, which cache settings should I check or modify to reduce the delay?
  3. Are there specific configuration parameters (e.g., cache timeouts or Celery settings) I should update to ensure immediate updates in the LMS?

Thanks in advance for your help!

1 Like

Hi @Mahendra I’m curious about a few things:

  • Why are you not running the latest Sumac release (Sumac.3) which contains latest sumac bugfixes and security fixes?
  • Have you tried Teak, and if the issue persists there?
  • Have you tried reindexing the course from Studio?

I concur with this delay behavior on fresh installs , but haven’t taken the time to write it out as thoroughly as you @Mahendra so thank you.

@dave volunteered as tribute for all things performance related in open edX so I’m going to tag him for visibility

I think this has to do with caching in the updated outline endpoint used for the left-hand navigation (though it’s also used elsewhere). My recollection is that it was at least partly cached on a per-user basis. I’ll look for the code in question the next time I’m in front of a computer.

Hi @sarina

Thank you for your assistance. I’ve also tried using Teak and reindexing the course, but the issue persists.

@dave, thank you for your response. I’d greatly appreciate your help in resolving this as soon as possible.

@Mahendra: Please try setting courseware.disable_navigation_sidebar_blocks_caching to True, and see if that helps. This is a course waffle flag, so it can also be overridden to be False on specific courses. My recollection is that the additional caching was added because the outline view was drilling down one layer of hierarchy deeper than it used to, which was causing performance issues on courses that had a large tree of content.

@Ivan_Niedielnitsev might know more.

Hi @dave,

I’ve set courseware.disable_navigation_sidebar_blocks_caching to True, but the changes still take approximately 5 minutes to reflect in the LMS. I’ve noticed that clearing the cache and logging back into the LMS causes the changes to appear immediately. However, I’m unable to locate where the cache duration (e.g., 5 minutes or 300 seconds) is configured.

@Ivan_Niedielnitsev, could you assist in identifying where this cache duration is set? I’ve reviewed the parameters in lms/envs/common.py and lms/envs/production.py but couldn’t find any settings related to a 5-minute cache duration.

Thank you!

Unfortunately, 5 mins is the Django default if no timeout is explicitly specified, so it’s sometimes harder to track down where it’s happening.

It’s a little odd that this is session-dependent, and not just user dependent, since user IDs sometimes end up in backend cache keys, but sessions almost never do. I wonder if that means the caching is happening on the frontend somewhere…