Currently, the loading sign shows indefinitely if the recommendation API response
is 200 with an empty recommended courses list. Fix, it by showing the general
recommendations.
VAN-1034
This commit updates the version of the lti-consumer-xblock from 4.3.2 to 4.3.3. This installs the newest version of the lti-consumer-xblock library. This version includes the following changes.
The error handler in LtiConsumerXBlock.lti_1p3_launch_callback logs a warning when a select set of exceptions are handled. That log does not contain useful information about the nature of the exception, because the exceptions were not being instantiated with error messages. The try...catch is a large block that contains code that can raise a multitude of errors, so these changes will enable better debugging.
This commit:
* adds helpful messages to the raised exceptions.
* adds the "exc_info=True" argument to include the stack trace of the handled exception.
* adds ValueError and TypeError to the list of handled exceptions, because the code can raise exceptions of these types.
The bug is explained in https://openedx.atlassian.net/browse/CRI-233. Only is missing add the `VisibilityTransformer` in `get_blocks()` when the user is not enrolled to the course.
On the test, `html_block` is visible only for staff and `vertical_block` is a normal block. The new behaviour hides the `html_block` and show the `vertical_block` to anonymous users
We already add the user id (imperfectly) to many requests.
However, when a user starts off unauthenticated, it is not
possible to correlate to those requests. Adding the raw
IP chain provides that possibility. See new custom attribute
ip_chain.raw.
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.
