When a student submits a problem answer, the state is stored in a
StudentModule record containing answer, score, correctness, etc. The
record, though, is updated in multiple steps within the single request
(first the grade is updated, then the state is updated separately).
Each partial save would trigger a separate StudentModuleHistory record
to be stored resulting in duplicate and inaccurate historical records.
This solution uses the RequestCache to track within a request thread
which StudentModules are updated and a single corresponding
StudentModuleHistory id. If multiple update actions occur within the
request cycle, then modify the history record that was already
generated to ensure that each submission only results in one
StudentModuleHistory record.
This issue and its solution were discussed in:
https://discuss.openedx.org/t/extra-history-record-stored-on-each-problem-submission/8081
Clearing the RequestCache was intended to address memory leaks in the
celery workers. Celery worker processes will process many tasks before
they are terminated. RequestCache cleanup typically happens in the
RequestCacheMiddleware class, and middleware never executes for celery.
To get around that issue, the CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION
setting was created to clear the RequestCache after every task was
successfully completed.
This works fine when celery is running as a separate process, as it's
set up to do in production. But during development, the
CELERY_ALWAYS_EAGER setting variable is set to True, meaning that
celery tasks are run in the same thread as the Django Request. This is
meant to make debugging easier, as task failures run as part of the
request cycle and will raise exceptions that are visible to the
browser.
However, celery tasks are triggered from many different actions. That
means that the RequestCache was being cleared many times during the
course of processing a request. This led to behavior that was
potentially slower, but also incorrect–the RequestCache was getting
flushed in a way that wouldn't happen in any deployed environment
because celery would be running in separate processes there. This came
up when trying to fix an issue around extra history records being
created during problem submissions:
https://discuss.openedx.org/t/extra-history-record-stored-on-each-problem-submission/8081
Furthermore, it's not necessary to prevent RequestCache memory leaks
when running in CELERY_AWLAYS_EAGER mode in development because the
middleware cleanup happens automatically–as everything is running as
part of the request/response cycle.
There are times in which we may want to run celery eagerly and still
clear the cache, such as testing. I have set
CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION = False in all dev and test
environments that already have CELERY_ALWAYS_EAGER = True. The unit
test that specifically tests whether the request cache is getting
cleared upon completion of a celery task then overrides
CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION = True even though
CELERY_ALWAYS_EAGER = True for the sake of that specific testing
purpose.
LMS Courseware access to Old Mongo courses was already removed in
fc8601de (https://github.com/openedx/edx-platform/pull/30172). This
commit makes direct links to the other tabs (progress, instructor
dashboard, discussion, static tabs) fail with a 404 error on Old
Mongo courses.
Upcoming work to remove parent/child relationships from the Old
Mongo Modulestore would have broken these pages anyway.
These changes should improve the performance caused by the file I/O
when it's running in docker, using lru_cache to save thousands of calls to listdir
when running with a handful of themes defined in COMPREHENSIVE_THEME_DIRS.
This attribute is already deprecated for XBlocks in favour of directly
retrieving it like `block.scope_ids.usage_id.context_key`.
This commit also removes some redundant logging code which was omitted in the
Datadog removal in #19420.
This argument was officially used only by the ProblemBlock.
If you need to get the base URL for static assets in your XBlock, please use
`settings.STATIC_URL` directly, instead of `runtime.STATIC_URL`.
This removes user-facing Studio edit support for Old Mongo courses
(courses that have a CourseKey of the format {org}/{course}/{run}).
This does not affect our normal courses, which have CourseKeys
starting with "course-v1:".
After this commit:
* Old Mongo courses will continue to appear on the Studio course
listing page, but are not clickable.
* Any attempt to directly access an Old Mongo course in Studio via URL
fail with a 404 error.
* Course certificates will still be available for Old Mongo courses.
* Old Mongo courses will continue to be returned by CourseOverviews
and get_course_summaries() calls.
We decided against removing Old Mongo courses from the listing entirely
because that would require very expensive CourseOverviews query to
filter them out. Making that query more efficient would involve a
database migration to add appropriate indexing, which is something else
that we are looking to avoid. CourseOverviews are used everywhere in
the system, so we want to avoid changing how they work so that we can
minimize risk.
This is part of the Old Mongo Modulestore deprecation effort:
https://github.com/openedx/public-engineering/issues/62
* fix: hide discussion xblock for openedx provider
* fix: test cases
* refactor: hide xblock is provider not legacy and add message in studio
* fix: lint issue
* refactor: update discussion block studio msg
* fix: test discussion xblock query number
It's safe to remove this because non-staff [1] users cannot access [2]
an `ErrorBlock`. We were able to reproduce this with and without this commit
with the following results:
1. Staff users were seeing the `ErrorBlock`.
2. Non-staff users were getting an empty `<div class="vert-mod"></div>`.
In theory, error blocks should be hidden in the Learning MFE because of this
option [3]. However, when we manually set `hide_access_error_blocks` to
`False`, we kept getting identical results (with and without this commit), so
it looks that the removal `NonStaffErrorBlock` was just omitted at some point.
[1] a4ec4c1b8e/lms/djangoapps/courseware/access.py (L419-L436)
[2] a4ec4c1b8e/lms/djangoapps/courseware/access.py (L150-L151)
[3] 92ca176fde/lms/djangoapps/courseware/views/views.py (L1547-L1551)
