* fix: Correcting logic for xblock_handler token expiration
The previous math had a date math error which resulted in token expiring in 0-2 days
instead of 2-4 days
Co-authored-by: Feanil Patel <feanil@edx.org>
Co-authored-by: Tim McCormack <tmccormack@edx.org>
Several tasks are explicitly named as (or like)
their old, deprecated import path.
The issue here is that django-user-tasks listens for task
invocations, and attempts to import the task based on its name.
If the task name is completely wrong, user-tasks will catch
the ImportError and move on.
If the task is a valid *deprecated* import, though, then
user-tasks will choke on the raised `DeprecatedEdxPlatformImportError`.
Thus, we must rename three tasks to their new full path:
1. entitlements.expire_old_enrollments
2. third_party_auth.fetch_saml_metadata
3. student.send_activation_email
The first two are run daily, and so are safe to be
renamed in place.
The third task must be renamed using an expand-contract
pattern; otherwise, we would drop hundreds of tasks
during the App vs. Worker out-of-sync version window
that happens at deployments.
This commit is the expand phase.
This includes the following settings:
- BLOCK_STRUCTURES_SETTINGS : setting dictionary which stores the other different block structures related settings
- BLOCK_STRUCTURES_SETTINGS['PRUNING_ACTIVE'] : keeps only a specific number of versions of each block structure, and deletes the rest
- BLOCK_STRUCTURES_SETTINGS['COURSE_PUBLISH_TASK_DELAY'] : specifies the delay, in seconds, after a new edit of a course is published before updating the block structures cache
- BLOCK_STRUCTURES_SETTINGS['TASK_DEFAULT_RETRY_DELAY'] : Specifies the delay, in seconds, between retry attempts for block structure tasks
- BLOCK_STRUCTURES_SETTINGS['TASK_MAX_RETRIES'] : specifies the max number of retries per block structure task
- BLOCK_STRUCTURES_SETTINGS['STORAGE_CLASS'] : specifies the storage which block structures would be saved to when storage backed block structures are enabled
Example: 'storages.backends.s3boto.S3BotoStorage'
- BLOCK_STRUCTURES_SETTINGS['STORAGE_KWARGS'] : specifies additional arguments needed when utilizing storage for storing storage backed block structures
Example: { bucket: 'test-edxapp' }
- BLOCK_STRUCTURES_SETTINGS['DIRECTORY_PREFIX'] : specifies the path to which storage backed block structures are saved
Example: '/courses/'
This also includes the following waffle switches:
- block_structure.storage_backing_for_cache : enables storage backed block structures, used to retrieve the block structures from storage instead of regenerating the structure, when not available in cache
it is important to note that this is important for production because it reduces response times on block structure related apis
- block_structure.raise_error_when_not_found : raises an error if the block structure requested doesnt exist in store or is outdated
- block_structure.invalidate_cache_on_publish : invalidates the block structure cache when courses are published
For an example with additional context, see the following forum post:
https://discuss.openedx.org/t/help-please-very-slow-load-time-10-seconds-for-courseware-on-sections-with-several-subsections-and-xblocks/2998/16
This also includes information about the toggles that will likely be deprecated and removed:
https://github.com/edx/edx-platform/pull/26175#issuecomment-769080286
