Skip to content

fix: give each course import its own working directory - #39109

Open
AhtishamShahid wants to merge 2 commits into
openedx:masterfrom
AhtishamShahid:ahtisham/hq-13190-concurrent-course-import
Open

AhtishamShahid wants to merge 2 commits into
openedx:masterfrom
AhtishamShahid:ahtisham/hq-13190-concurrent-course-import

Conversation

@AhtishamShahid

@AhtishamShahid AhtishamShahid commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

Description

Two people importing the same course at the same time would break each other: every import of a course used one shared working directory, so whichever import finished first deleted the other's archive and extracted files mid-run. The second import then failed with a bare [Errno 116] Stale file handle ([Errno 2] on a local disk) that told the author nothing. Each import and each upload now gets its own private subdirectory, so both imports succeed instead of one failing. Affects Course Authors on any site where two people can import the same course; no config, migration, or API change.

Supporting information

Reported on courses.learn, where two authors imported the same course two minutes apart. The originating ticket (mitodl/hq#13190) is private, so the log is repeated here:

17:28:22Z  import_olx[a2116d7a] received
17:30:21Z  import_olx[7acd83da] received
17:31:24Z  import_olx[a2116d7a] Course import successful
17:31:28Z  import_olx[7acd83da] Error while importing course: [Errno 116] Stale file handle

Testing instructions

  1. Export a reasonably large course from Studio, so an import takes a minute or more.
  2. As author A, start importing that archive into a course.
  3. As author B, start importing the same archive into the same course while A is still running.
  4. Both should report "Course import successful", and GITHUB_REPO_ROOT should have no leftover directory for that course.
  5. Or run pytest cms/djangoapps/contentstore/views/tests/test_import_export.py::ConcurrentImportTestCase, which fails on the parent commit with the production error and passes here.

Already run locally on Python 3.12 in an openedx-dev:22.0.0 container: the four affected suites give 149 passed and 2 failed, where those 2 fail identically on the unpatched files (skew between that image's baked tree and master) and ruff check is clean; CI has not run yet.

Other information

This does not make two concurrent imports of different archives into one course safe — they both rewrite the same course structure, so the result is whichever finishes last; refusing the second import up front would close that too, but it changes product behavior and is deliberately left out here.

Every import of a given course used a single working directory derived
from the course key alone, shared by the import task and by both upload
views. Two imports of the same course therefore overwrote each other's
archive, and whichever import finished first deleted the other's
extracted OLX mid-run. The surviving task failed with a bare filesystem
error: "[Errno 116] Stale file handle" on an NFS-backed
GITHUB_REPO_ROOT, "[Errno 2]" on a local disk.

Add course_import_working_dir() and remove_course_import_working_dir(),
and use them from import_olx and from both upload views so that every
import and every upload gets a private subdirectory. Both upload views
now drop their staging copy once the archive is in storage; previously
they relied on the import task's cleanup of the shared directory.

Cleanup no longer raises, so a failing cleanup can no longer mask the
error that triggered it.
@openedx-webhooks

Copy link
Copy Markdown

Thanks for the pull request, @AhtishamShahid!

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

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:

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.

@openedx-webhooks openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Sep 16, 2026
@github-project-automation github-project-automation Bot moved this to Needs Triage in Contributions Sep 16, 2026
@AhtishamShahid
AhtishamShahid requested review from dwong2708 and salman2013 and removed request for dwong2708 September 16, 2026 10:30
@mphilbrick211 mphilbrick211 moved this from Needs Triage to Ready for Review in Contributions Sep 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

open-source-contribution PR author is not from Axim or 2U

Projects

Status: Ready for Review

Development

Successfully merging this pull request may close these issues.

3 participants