fix: move BlockKey and derived_key to avoid cyclical import #34051
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
After we merged this PR: openedx#33920 this error began popping up in logs: Unable to load XBlock 'staffgradedxblock' .... ImportError: cannot import name 'get_course_blocks' from partially initialized module 'lms.djangoapps.course_blocks.api' (most likely due to a circular import) ... The root cause was the new imports of `derived_key` and `BlockKey` into xmodule/library_content_block.py. Those new imports come from xmodule/modulestore/store_utilities.py, which runs `XBlock.load_classes()` at the module level, which fails because we are still in the process of loading xmodule/library_content_block. As a solution, we move both `derived_key` and `BlockKey` to xmodule/util/keys.py. We could potentially move that file to opaque-keys eventually, depending on how well we think that those concepts generalize. Also: * We rename the function from derived_key to derive_key, as functions should be verbs. * We combine the first to parameters of derive_key (a source ContextKey and a source BlockKey) into a single parameter (a source UsageKey). In my opinion, this makes the function call easier to understand.
kdmccormick
force-pushed
the
kdmccormick/derived-key
branch
from
90db189
to
e064bf9
Compare
UsageKeys don't have a usage_id field. This line would have crashed if run.
connorhaugh
approved these changes
Jan 16, 2024
|
2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production. |
|
2U Release Notice: This PR has been deployed to the edX production environment. |
1 similar comment
|
2U Release Notice: This PR has been deployed to the edX production environment. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Problem
After we merged this PR:
This stack trace began popping up in logs:
Although the trace doesn't make it obvious, the root cause was the new imports of
derived_keyandBlockKeyinto xmodule/library_content_block.py. Those new imports come from xmodule/modulestore/store_utilities.py, which runsXBlock.load_classes()at the module level, which fails because we are still in the process of loading xmodule/library_content_block (so, a cyclical import).Strangely, this cyclical import didn't crash the server or cause any static analysis to fail. In the interest of removing log noise and avoiding unknown buggy behavior, though, we'd like to break this import cycle.
Solution
We move both
derived_keyandBlockKeyto xmodule/util/keys.py. We could potentially move that file to opaque-keys eventually, depending on how well we think that those concepts generalize.Also:
Supporting information
None
Testing instructions
None
Deadline
ASAP--blocks #33511
Other information
None