[CLOSED] FC-0026 - XModule Assets (Phase 1)

 

Funded Project ID

FC-0026

Provider

OpenCraft

Axim Contact(s)

Dave Ormsbee

Expected Completion Date

September 1, 2023

Status

Complete

Additional Project Details

This project continues ModuleStore simplification and also addresses a class of bug discovered when completing BD-13. Specifically, this project removes block-specific handling when initializing the XBlock runtime for a given user. This means:

  • The code is much simpler, particularly prepare_runtime_for_user, and it aligns to new developer expectations of how this method should work.

  • We create and initialize far fewer runtime service objects, leading to CPU and some memory savings.

  • We are no longer vulnerable to the kind of regression that we ran into at the end of BD-13.

GitHub

Pull requests · openedx/edx-platform

 

Before BD-13, there was a separate XBlock runtime object created for each block (problem, HTML, video, etc.). This was a known source of confusion and memory leaks that had caused many operational problems over the years. BD-13 simplified this by making a single runtime object, but the runtime services would be re-created and initialized for each block. This resulted in a regression w.r.t. anonymous ID generation in the runtime services because anonymous ID behavior is different for certain legacy block types–and in fact this edge case behavior only occurred on one code path where there were access checks being made at the SequenceBlock level that overrode the runtime values set at the ProblemBlock.

The short term fix for that problem was made here, but we were still vulnerable to similarly serious and difficult-to-debug corner cases around initialization ordering. The longer term fix to avoid this entire class of issues was to make the runtime only initialize its services once. This meant eliminating block-specific initialization behavior, like in the case of anonymous ID generation. Fortunately, this aligned well with how we wanted to evolve the runtime in the longer run anyway.

The end result of this project is that the XBlock runtime is no longer vulnerable to the runtime block execution ordering bugs above. It is also much simpler to understand (particularly the critical prepare_runtime_for_user function), since it finally brings the code to align with how most people intuitively expected it to work. There are also some modest CPU and possibly memory improvements that come from this work, but that was not the primary goal.