Background

We’re working to understand several related bugs that existed (or exist?) in Content Libraries V1 so that we don’t bring them back in Content Libraries V2.

Some of these links are internal to 2U and Axim. Ping us if you’d like to see a redacted version.

Unstable randomization

• PR: Fix the unpredictable order randomization issue with randomized content blocks

  • And previous iterations of the same PR:

    • https://github.com/openedx/edx-platform/pull/23265

    • https://github.com/openedx/edx-platform/pull/20723

    • https://github.com/openedx/edx-platform/pull/18675

  Jira

Issues with update_children

• The incident that kicked it all off: CR-2568: Learner library state needs to be restored in course-v1:REDACT to preserve correct grades.

  • ^ Notes on that Jira ticket

    • Monica’s notes

  • Team “fixed” this by disabling library_content child refresh on import

• A few months later: Jira: Randomized Content Block Settings Lost in Course Import

  • This was caused by a flawed fix to the previous Jira ticket

  • Caused by disabling of child refresh (in response to previous CR)

  • Fix: PR: Re-enable refreshing from library only on initial insertion of lib

    Fixes this Jira ticket, while taking care not to re-introduce the bug from the original Jira ticket.

    • Dave O re-enables child refresh here, but with an extra condition: “when importing, do not update_children if library_content block is already published”

    • This condition should theoretically prevent CR-2568 from resurfacing. That is, it should prevent library_contents' childrens' block IDs from changing when a course is imported.

• Dave’s fix amounts to this:

  • Code Block
    language none
    if block.location.block_type == 'library_content': if block.source_library_id and store.get_library(block.source_library_key): + if store.has_item(module.location): # is library_content block already published? + return block with store.branch_setting(branch_setting=ModuleStoreEnum.Branch.draft_preferred): LibraryToolsService(store, user_id).update_children( block, version=block.source_library_version, )

• Here’s the thing: I don’t exactly understand why Dave’s fix would have prevented CR-2568. Some scenarios:

  • Debunked theories:

    • The keys of the library_content children changed because they weren’t stable. This is bunk because child IDs are deterministically calculated from (course_key, library_content.key, library_source_block.key). None of those would change given the CR-2568 scenario.

    • The authors deleted blocks from the library. Then, re-importing the course updated the the library_content block’s source_library_version, causing library blocks children to disappear from the course. The thing is, this doesn’t make sense, because the import code even without Dave’s new condition does not update the source_library_version. I confirmed this locally.

    • The authors deleted the library_content block itself, and upon re-import of the course, new library_content children were selected. This doesn’t make sense because selected is a user_state field, which would not be deleted even if its corresponding library_content block was removed. Furthermore, source_library_id and source_library_version are stored as settings in the course export, so it’s not like those fields are lost.

    • The authors deleted the library_content block itself. The authors also deleted blocks from the library. Several library edits later, the version of the library that the course uses is pruned away. Thus, upon re-importing the course, the latest library version is used instead. This doesn’t make sense, because (a) it’s contrived, and (b) library_content does not “fall back to latest” if the specified version is missing… the whole import would have failed! (in 2021, this was changed to log an error but let the import succeed).

  • Open theories:

    • ???

Takeways

WIP