We have found that for many courses on edx.org, the "current version"
of the course that's stored in MongoDB doesn't match what's stored in
MySQL. Although this doesn't directly cause any problems as the
"current version" (course index) is not normally read from MongoDB,
it's not supposed to happen - and it can cause problems if some other
extra-platform components (like a pruner script) read the course
indexes out of MongoDB.
We still aren't sure what can cause MongoDB and MySQL to get out of
sync in the first place; this won't necessarily fix that issue. What
this does fix is a bug that seems to be: once they get out of sync,
they stay out of sync and mongo will stop receiving writes.
The Mongo code in most cases will only write a new record if the
"current" record's last_update matches the last_update value before
the change was made. e.g. last_update is "10am", user makes a change,
Mongo gets updated only if the current row's last_update is still
"10am". Otherwise it's considered a "collision" and silently ignored.
Once Mongo and MySQL somehow become out of sync, they may stay out of
sync because any new writes will have a last_update value read from
MySQL, which is newer than the value in MongoDB, so the MongoDB writes
will all be rejected as "collisions".
This should fix the issue by making mongo writes always match the MySQL
writes, instead of letting the Mongo code "decide on its own" when to
write course index updates or not.
This commit updates the version of the lti-consumer-xblock from 4.3.1 to 4.3.2. This installs the newest version of the lti-consumer-xblock library. This version includes the following changes.
This commit adds supplemental logging to diagnose the bug reported in MST-1540: https://2u-internal.atlassian.net/browse/MST-1540. The bug is that learners are encountering the LtiError when trying to do an LTI launch. The learners appear to be authenticated, so this error should not occur. The bug is not easily reproducible in production or development, so this supplemental logging is added to help understand the user's state when the error is raised.
The current hypothesis is that user is temporarily represented by the AnonymousUser in the request that is made when doing the LTI launch, despite the user otherwise being authenticated. Logging in Splunk suggests that this is the case, because logs are of the following form, "2022-07-22 15:10:14,214 ERROR 5067 [django.request] [user None] [ip <ip>] log.py:224 - Internal Server Error: /courses/<course_key>/xblock/<usage_key>/handler/lti_launch_handler", where the "user" is "None". This logging should prove or disprove this hypothesis and provide direction about where else to look.
This logging should be removed once MST-1540 is resolved.
This commit updates the version of the lti-consumer-xblock from 4.3.0 to 4.3.1. This installs the newest version of the lti-consumer-xblock library. This version includes the following changes.
This commit fixes three bugs.
1. The first bug is that the lti_version field is inappropriately hidden in the Studio author view edit menu when the selected config_type is database.
2. The second bug is that the editable_fields property of the LtiConsumerXBlock is inappropriately excluding LTI 1.3 fields when the config_type is database. The editable_fields property should include LTI 1.3 fields even when the config_type is database, because the Javascript defined in xblock_studio_view.js may want to show these fields if the user selects a different config_type in the menu. We want to support a dynamic edit menu, so these fields must be considered editable by the XBlock in order for the Javascript to be able to manipulate them.
3. The third bug is in inconsistent rendering of the Studio author view edit menu. Depending on the order in which a user selects lti_version, config_type, or lti_1p3_tool_key_mode, different sets of fields are displayed, due to the overlapping sets of rules that govern what fields should be hidden or shown for a given field selection. This commit corrects this inconsistent rendering by first showing all fields and then gradually hiding fields depending on the sets of rules, for each change to the fields.
The decision to provide Restricted Applications expired
JWTs was superseded by another ADR. This commit simply
adds clarity around that change.
Co-authored-by: Phillip Shiu <pshiu@users.noreply.github.com>
This setting allows loading of Resource Templates from outside the
edx-platform codebase.
Operators will be able to add their own custom resource templates
without needing to fork the codebase.
