perf: bulk-prefetch grades in ProblemGradeReport and bound its per-learner caches

[blarghmatey]

What

Addresses four of the five findings in #38943. The remaining one (Finding 4, streaming
the report upload through DjangoStorageReportStore.store) is left for a separate PR
because it touches shared storage code used by every instructor-task report, not just
grade reports, and wants its own test pass.

Why it matters

ProblemGradeReport read persisted grades one learner at a time, unlike
CourseGradeReport, whose _rows_for_users opens with a _CourseGradeBulkContext. With
nothing prefetched, PersistentSubsectionGrade.bulk_read_grades missed the per-course
RequestCache and fell through to a query per learner — and this report walks
course_grade.problem_scores, so it touches more subsection data per learner than the
course report does.

The issue flagged the attribution as unmeasured. It is now measured, with
CaptureQueriesContext around the report while varying cohort size:

learners	5	10	25	50
before	20	30	60	110
after	13	13	13	13

Before fits 2N + 10; after is flat. At a full 100-learner batch that is 210 queries
versus 13, and the report batches at 100, so a 5,000-learner course goes from roughly
10,500 grade-related queries to about 700.

Changes

Finding 1 — bulk prefetch. New _ProblemGradeBulkContext, deliberately narrower than
_CourseGradeBulkContext: the problem report emits no cohort, team, certificate or
course-tag columns, so prefetching those would be wasted work. It loads persisted course
and subsection grades plus enrollment states, which is what the rows actually read.

Finding 2 — double block-structure load. graded_scorable_blocks_header now passes
the already-loaded structure to grading_context() instead of calling
grading_context_for_course(), which re-enters get_course_in_cache.
BlockStructureManager.get_collected() deserializes fresh from the cache backend on every
call, so a large course paid that cost — and its peak allocation — twice.
CourseGradeReport already does this correctly.

Finding 3 — unbounded per-learner caches. RequestCache is only flushed on
task_postrun. Unlike the course-keyed grade prefetches, which are replaced wholesale
each batch, the visible-blocks and subsection-override caches are keyed per
(user, course) and only ever grow — yet nothing reads an entry again once that learner's
row has been written. The _clear_caches hook already existed and was already called per
batch; the base implementation was simply empty. This adds the missing
clear_prefetched_data() counterparts to VisibleBlocks and
PersistentSubsectionGradeOverride, plus a
clear_prefetched_grade_overrides_and_visible_blocks() api function pairing with the
existing prefetch_grade_overrides_and_visible_blocks().

Finding 5 — dead constant. USER_BATCH_SIZE was defined on CourseGradeReport but
never referenced, so the effective batch size was grouper's hardcoded default and tuning
the constant did nothing. Moved to GradeReportBase and wired through, so both reports
honour it.

Testing

• lms/djangoapps/instructor_task/tests/test_tasks_helper.py — 104 passed (103
  existing plus the new query-count test).
• lms/djangoapps/grades/tests/ — 741 passed, including the existing
  test_query_counts assertions, which are unchanged.
• The pre-existing TestInstructorGradeReport::test_query_counts assertion for
  CourseGradeReport (48 queries) still passes unmodified, confirming the shared
  _clear_caches and USER_BATCH_SIZE changes do not alter that report's behaviour.

The new test asserts the same query count at two different cohort sizes rather than one.
That is the point of it: a single-size assertion would keep passing if the per-learner
read crept back in.

Backward compatibility

CSV contents and format are unchanged. No schema or data migration. Findings 1–3 reuse
helpers the codebase already relies on; the only new public surface is the
clear_prefetched_* counterpart to an existing prefetch_* function.

Context

Found while investigating a 5,154-learner course whose problem grade report took ~80
minutes end to end, of which the CSV upload was 0.17s — essentially all of it in the
per-learner compile loop. Related: #38911 proposes bringing the same CourseGradeReport
bulk-prefetch pattern to the synchronous CCX grade report; same defect class, different
code path.

[openedx-webhooks]

Thanks for the pull request, @blarghmatey!

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:

• 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.

[blarghmatey]

@openedx/wg-maintenance-openedx-platform-oncall — this is ready for engineering review.

Checklist from the bot above:

• Product approval — not applicable. No user-facing or behavioural change: CSV contents and format are byte-identical, and there is no schema or data migration. This is purely a query-count and memory reduction inside ProblemGradeReport.
• Context — in the description, including the measured before/after query counts and the linked issue (Performance: ProblemGradeReport reads persisted grades per-learner (no bulk prefetch), plus four resource issues in instructor_task grade reporting #38943).
• Green build — 42/42 checks passing.

Short version: ProblemGradeReport read persisted grades one learner at a time, where CourseGradeReport already bulk-prefetches per batch. Measured with CaptureQueriesContext while varying cohort size, the query count fit 2N + 10 before and is a flat 13 after — so a 5,000-learner course drops from roughly 10,500 grade-related queries to about 700. A regression test asserts the flat count at two different cohort sizes, since a single-size assertion would keep passing if the per-learner read crept back in.

Also folds in three smaller fixes from the same issue: a double block-structure deserialization, two per-learner RequestCaches that were never evicted across a long task, and a USER_BATCH_SIZE constant that was defined but never wired up.

Related: #38946 does the remaining finding from #38943 (streaming the report upload). Independent of this one — they touch different parts of grades.py and can land in either order. #38911 proposes the same bulk-prefetch pattern for the synchronous CCX grade report.