Bugs from Content Libraries V1

Owned by Kyle McCormick
Last updated: Sept 07, 2023
3 min read

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

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.

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

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

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

      • 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:

    • 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 certain library_content 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:

      • The authors deleted blocks from the library. After re-importing the course, they also hit “Update now” on a library_content block. This caused certain library_content children to disappear from the course. The issue with this theory is that there is no mention of the course team deleting content from the libraries themselves OR hitting “Update now” in the course. That doesn’t mean it’s not plausible, just less likely.

Takeways

WIP