fix: course import when lib block is synced

[asadali145]

Description

Fixes a crash when importing a course containing a library_content block into an environment where that course does not yet exist, but the referenced v1 library does.

Problem

When exporting a course from one environment (e.g. production) and importing it into another (e.g. RC/staging) for the first time, the import fails with:

KeyError: BlockKey(type='problem', id='...')
BlockFailedToImport: Failed to import block: <name> at location: i4x://.../library_content/...

This only occurs when all three conditions are met simultaneously:

1. The library_content block had its children synced from the library before export (so the exported XML contains child problem block IDs)
2. This is the first import of the course to the destination (the library_content block has never been published there)
3. The referenced v1 library exists on the destination

Root Cause

The _update_and_import_block function in xml_importer.py has special-case handling for library_content blocks. During a course import, children are imported under the published_only branch setting. split_draft.import_xblock under this setting imports the block to the draft branch and then immediately publishes it with blacklist=EXCLUDE_ALL (no children). It returns the published block.

Two bugs compounded:

Bug 1 — sync called on wrong branch:
sync_from_library() was called on the returned published block. The trigger_library_sync Celery task calls store.get_item(dest_block.scope_ids.usage_id) — since the usage ID already carries branch=published, _map_revision_to_branch ignores the surrounding draft_preferred branch setting and fetches the published block. copy_from_template then creates child blocks only in the published structure. When store.publish() subsequently copies from draft → published, the draft structure has a dangling child reference (from the XML import) but no actual block entry for it, causing the KeyError.

Bug 2 — stale library version GUID:
Even after fixing Bug 1 (calling sync_from_library on the draft block), the sync still silently failed. sync_from_library() without upgrade_to_latest=True passes source_library_version — a MongoDB ObjectId from the source environment's database — to trigger_library_sync. That version GUID does not exist in the destination's MongoDB, so get_library(...for_version(source_version_guid)) raises ItemNotFoundError → ObjectDoesNotExist, which is swallowed by the inner except ObjectDoesNotExist: pass. The else block then proceeds to call store.publish() on a draft structure that still has only dangling child references — same crash.

Fix

Two changes to _update_and_import_block in xmodule/modulestore/xml_importer.py:

1. Explicitly fetch the draft block and call sync_from_library on it, so copy_from_template populates child blocks in the draft structure (not the published structure).
2. Pass upgrade_to_latest=True so the library is resolved against the destination environment's current library head, rather than attempting to look up a version GUID from the source environment that will never exist on the destination.

# Before
with store.branch_setting(branch_setting=ModuleStoreEnum.Branch.draft_preferred):
    try:
        block.sync_from_library()
    except ObjectDoesNotExist:
        pass

# After
with store.branch_setting(branch_setting=ModuleStoreEnum.Branch.draft_preferred):
    try:
        draft_block = store.get_item(
            block.location.for_branch(ModuleStoreEnum.BranchName.draft)
        )
        draft_block.sync_from_library(upgrade_to_latest=True)
    except ObjectDoesNotExist:
        pass

After these fixes, copy_from_template correctly creates child problem blocks in the draft structure, and the subsequent store.publish() can recursively copy them from draft → published without a KeyError.

Notes

• The upgrade_to_latest=True behaviour on first import is safe and intentional: the existing guard if lib_content_block_already_published: return block ensures subsequent re-imports skip the sync entirely, preserving student state.
• This is a first-import-only code path. Re-imports of a course that already has a published library_content block are completely unaffected.

Testing instructions

To reproduce the bug (before the fix), we need to have 2 open edx instances:

• Create a v1 legacy library with at least one problem block
• Create a course with a library_content unit pointing to that library
• Click "Update Now" in Studio to sync the library content block (this populates children in the draft structure)
• Export the course as a .tar.gz
• Export the library and import on the second instance
• Import the course .tar.gz on second instance → import fails with BlockFailedToImport
• To verify the fix:
  • Repeat the steps above with the fix applied → import succeeds
  • Verify the library_content block is visible and functional in Studio after import
  • Re-importing the same course a second time should also succeed.

[openedx-webhooks]

Thanks for the pull request, @asadali145!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.