Bug: calculate_problem_responses_csv raises UsageKeyNotInBlockStructure with no way for the instructor to see it

[bmtcril]

POST /api/instructor/v2/courses/<key>/reports/problem_responses/generate for a
problem whose section was published within the last publish-task delay (~30 s on
Tutor) answers 200, and the task then raises UsageKeyNotInBlockStructure. The
report reads the collected block structure, which the delayed publish task
rebuilds.

There is no task id returned for this task to read the failure from, and
instructor_tasks lists only running tasks, so it is simply empty. To the
instructor the report just never appears, with no error anywhere in the UI.

Expected: validate the location against the collected structure in the view
and answer 400 with a clear message, or have the task fall back to the
modulestore. Returning a task id as other tasks do would also let a client surface
the failure.

[Swir]

Hi! This appears to involve both a block-structure timing issue and missing visibility into asynchronous task failures.

A proposed first step is to validate that the requested problem exists in the collected block structure before scheduling the report. If it is not available yet, the endpoint could return the suggested HTTP 400 response with a clear message explaining that course publication is still being processed and the request should be retried.

That preflight check should not be the only protection: the task should still handle UsageKeyNotInBlockStructure and record a readable failure if the structure changes between validation and execution.

Returning a task identifier and exposing its final status would also let the UI show failures instead of leaving instructors waiting indefinitely. That could be a separate follow-up if it broadens this fix too much.

Regression coverage should include:

• A newly published problem absent from the collected structure.
• A problem already present in the structure.
• A task-time failure after successful preflight validation.

I would avoid an automatic modulestore fallback until its consistency with the report’s collected-structure behavior is established.

This is a proposed direction based on the issue description; it has not been tested against the repository.