After refactoring the library_content block to use asynchronous tasks
for syncing and duplicating children, we are seeing an error arise
during library_content duplication process on edx.org:
Traceback (most recent call last):
File "/edx/app/edxapp/edx-platform/openedx/core/djangoapps/content_libraries/tasks.py", line 305, in duplicate_children
_copy_overrides(store=store, user_id=user_id, source_block=source_block, dest_block=dest_block)
File "/edx/app/edxapp/edx-platform/openedx/core/djangoapps/content_libraries/tasks.py", line 383, in _copy_overrides
dest_block=dest_block.runtime.get_block(dest_child_key),
File "/edx/app/edxapp/edx-platform/xmodule/x_module.py", line 1401, in get_block
block = self.load_item(usage_id, for_parent=for_parent)
File "/edx/app/edxapp/edx-platform/xmodule/modulestore/split_mongo/caching_descriptor_system.py", line 127, in _load_item
block_data = self.get_module_data(block_key, course_key)
File "/edx/app/edxapp/edx-platform/xmodule/modulestore/split_mongo/caching_descriptor_system.py", line 154, in get_module_data
raise ItemNotFoundError(block_key)
xmodule.modulestore.exceptions.ItemNotFoundError: BlockKey(...)
We cannot reproduce the issue locally.
We are not entirely certain the cause of this, but we think it might
have do with caching. Specifically, the `store.get_item` and
`source_block.runtime.get_block` methods might use a different cache
than `dest_block.runtime.get_block`. It's possible that writes to
Mongo are sitting in one of those caches, causing reads from the
`dest_block.runtime`'s cache to fail to find dest_block's children.
We attempt to fix this by using the same "block getting" method
consistently. So instead of using a mix of `store.get_item`,
`source_block.runtime.get_block`, and `dest_block.runtime.get_block`,
we just use `store.get_item` everywhere.
129940b562