build: bump xblocks-contrib to 1.0.3 (fixes author-side ungraded problems, mitodl/hq#12023)

[AhtishamShahid]

Draft — do not merge. Blocked on openedx/xblocks-core#286. See "Sequencing" below.

What this fixes

A problem added to a graded subsection displays as 0 points / ungraded — but only to the author who created it. Everyone else sees it correctly, and duplicating the problem also renders correctly.

get_progress() reads grading off the persisted user-state score, and the author ends up with a stale one:

1. Author adds a problem. Nothing is filled in yet, so max_score() is 0.
2. Studio renders it. lcp sees score is None and persists Score(0, 0) — for this author only.
3. Author fills the problem in and saves. max_score() is now 1.
4. lcp will not refresh the score, because score is no longer None, so raw_possible stays 0.
5. get_progress() returns None, and the author sees 0 points, ungraded.

Any other user has no persisted state, so their score reflects the current problem (Score(0, 1)) and they correctly see 1 point possible (graded). That asymmetry is what made this confusing to report.

Fixed upstream in openedx/xblocks-core#272, released in xblocks-contrib 1.0.3 on 2026-07-29. It has never reached a deployment because this repo is still pinned to 0.17.0.

This affects the code that actually runs: USE_EXTRACTED_PROBLEM_BLOCK defaults to True, so xmodule.capa_block.ProblemBlock resolves to xblocks_contrib.problem.capa_block.ProblemBlock at runtime.

Why the pin is stuck at 0.17.0

Not lag — a deliberate revert. 2d315ebd69 ("build: downgrade xblocks-contrib — The renaming is causing some conflicts and causing tests to fail") reverted the bot's bump from 1.0.1, because no 1.0.x wheel ships xblocks_contrib.problem.capa.tests, which this repo imports from 17 of its own test modules.

Pinning the released 1.0.3 fails every unit-test shard with ModuleNotFoundError: No module named 'xblocks_contrib.problem.capa.tests' — demonstrated on this branch earlier, run 31097321942. The blast radius is wider than the direct importers, since lms/djangoapps/grades/tests/base.py is imported transitively.

That is an upstream packaging bug, fixed by openedx/xblocks-core#286.

The two commits

commit	what
937130356a	update all 17 importers to the relocated fixture paths
8c7c17a4fe	bump the requirement — the only commit that changes when 286 releases

Import changes, per openedx/xblocks-core#286:

capa.tests.response_xml_factory         →  capa.testing.response_xml_factory
capa.tests.test_util.UseUnsafeCodejail  →  capa.testing.codejail.UseUnsafeCodejail

The requirement currently points at that PR's branch (f532c455cd) so CI can run green against the fix. Verified locally with that wheel installed (Py3.12): the previously-erroring modules collect with 0 errors, xmodule/tests/test_capa_block.py passes 201/201, and the reported bug is gone — the author now gets Progress(0, 1) / (0, 1) instead of None / (0, 0).

Compile requirements and check_dependencies are expected to fail while a VCS requirement sits in the compiled files.

Sequencing

1. fix: publish shared capa fixtures from a testing package xblocks-core#286 merges and releases as 1.0.4 (CI green there).
2. This PR swaps the VCS reference for xblocks-contrib==1.0.4 — a one-commit amend — and comes out of draft.

No changes to this repo's own source are needed — only test imports and the pin.

Note on the built-in copy

xmodule/capa_block.py's _BuiltInProblemBlock.get_progress has the same defect, so deployments running USE_EXTRACTED_PROBLEM_BLOCK = False stay affected after this bump. Left alone here since #38751 removes that implementation — happy to port the guard across if you'd prefer an interim fix.

[openedx-webhooks]

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.

🔘 Update the status of your PR

Your PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate.

---

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.

[AhtishamShahid]

CI evidence from the first commit

cc254a0708 ("build: bump xblocks-contrib to 1.0.3") pinned the released 1.0.3 and CI failed as expected. Every unit-test shard errored at collection:

• lms-1, lms-3, lms-4, lms-5, cms-1, cms-2, shared-with-lms-1, shared-with-lms-2, shared-with-cms-1 — all fail
• Unit tests successful (the aggregate gate) — fail

with the cause visible in the logs (run 31097321942):

ModuleNotFoundError: No module named 'xblocks_contrib.problem.capa.tests'

The blast radius in CI is wider than the 17 modules that import those fixtures directly — lms/djangoapps/grades/tests/base.py is imported transitively, so mobile_api, bulk_email and support test modules error out too.

Current state: draft, pointing at the fix branch

6a705d05a2 repoints the requirement at the branch behind openedx/xblocks-core#286, which fixes the wheel packaging. Verified locally against an openedx-platform checkout on Python 3.12:

version: 1.0.3
fixture imports from git install: OK
940 tests collected in 0.78s        # 0 collection errors

and xmodule/tests/test_capa_block.py → 201 passed.

Note the Compile requirements / check_dependencies jobs are expected to object to a VCS requirement in the compiled files — that is inherent to this temporary reference state, not a problem with the bump.

Next step

Once #286 merges and releases as 1.0.4, I'll replace the VCS reference with the released pin and take this out of draft. No changes to this repo's own code are needed — the only reason the bump was reverted in 2d315eb is the upstream packaging bug.

[AhtishamShahid]

Updated for the long-term upstream shape

openedx/xblocks-core#286 has been reworked. Rather than re-shipping a tests/ package, it moves the capa fixtures into a capa/testing/ package that is not under a tests/ directory — so nothing test-shaped ships and no test-exclusion glob can strip them again. That changes import paths, so 4906d312ce here updates all 17 importers:

capa.tests.response_xml_factory          -> capa.testing.response_xml_factory
capa.tests.test_util.UseUnsafeCodejail   -> capa.testing.codejail.UseUnsafeCodejail

Verified with the resulting wheel installed on Python 3.12: the previously-erroring modules collect cleanly (1281 tests collected, 0 errors) and xmodule/tests/test_capa_block.py passes 201/201.

The VCS reference now points at that PR's latest commit. Sequencing is otherwise unchanged: once #286 merges and releases, this goes back to a released pin (xblocks-contrib==1.0.4) and comes out of draft. The Compile requirements / check_dependencies failures remain expected while a VCS requirement sits in the compiled files.

[AhtishamShahid]

Rewrote this branch to clean history — the two TEMP commits and the intermediate 1.0.3 pin are gone. It is now two commits:

1. 54c09e4cbe — the 17 import updates
2. 7922a93b26 — the requirement bump, the single commit that changes when fix: publish shared capa fixtures from a testing package xblocks-core#286 releases

The CI evidence for the original failure is preserved in run 31097321942 and referenced from the description, so dropping that commit loses nothing.

Also note openedx/xblocks-core#286 has itself been trimmed to the minimum — it no longer touches pyproject.toml at all — so the requirement here points at its new head.