fix: refresh course structure on Android

[edschema]

Description

Fixes a course-refresh issue on Android. When the app asked to refresh course structure while online, it could return the first saved copy and stop before making a new request. That saved copy can be out of date. iOS already makes a fresh request in this situation.

Now, when a caller explicitly asks for a refresh and the app is online, Android sends a Cache-Control: no-cache request. A saved response must be checked before it can be reused. This request is separate from ordinary course loading. An explicit refresh while offline still reads only saved data. Ordinary course loading remains cache first.

This better aligns Android's course-refresh behavior with iOS. It is also an Android prerequisite for later course-routing work. The routing change will be a separate PR after this one merges. Both PRs must land before mobile Inbox can be enabled.

Out of Scope

This PR does not add Inbox or routing behavior. It does not change the server API, database schema, database migrations, or the caching behavior for status, dates, progress, or enrollment. It adds tests that confirm the existing status, dates, and progress flows still recognize a refresh request after an earlier course-structure request finishes.

Change Log

• Send only explicit online refreshes through the new Cache-Control: no-cache request path.
• Allow matching refresh requests to share one request, but never let a refresh reuse an ordinary cache-first request.
• Keep an older request from changing the current course session after the learner leaves and reopens a course.
• Ensure an older cache-first result does not replace a newer refreshed course structure.
• Clarify the code comments that explain request cancellation, course sessions, and database writes.
• Add focused tests for online and offline behavior, request headers, request sharing, request failures, delayed database work, session reset, and existing status, dates, and progress refresh checks.

Notes

An explicit online refresh that fails does not silently return older course structure. An explicit offline refresh continues to use saved data only.

A refresh cannot reuse an ordinary course-loading request because the two requests have different cache rules.

The existing Dates caller that asks for a refresh benefits from this change. No Dates code changes are included.

CourseInteractor now checks network availability before choosing the refresh path. Its public interface and the course API contract are unchanged.

Tests Done

• Added focused unit tests covering:
  • Online refresh routing, offline use of saved data, an offline cache miss, and ordinary cache-first loading in CourseInteractorFreshTest
  • A fresh response saving to the local database and memory, and a failed fresh request returning an error instead of saved data, in CourseRepositoryFreshTest
  • Separate HTTP cache headers for fresh and ordinary requests, matching fresh requests sharing one request, and a fresh request never sharing an ordinary request
  • An older ordinary request or delayed local-database read not replacing a completed refresh
  • Session reset: older work cannot update a later course session, and a later write becomes the final saved value when an earlier database write was already in progress
  • Existing status, dates, and progress refresh checks remaining active after an older course-structure request finishes
  • Cache writes and request cancellation: an older result cannot replace a newer cached value, and cancelling an earlier request cannot remove a later pending request in CoalescingCacheTest
• :course:testDevelopDebugUnitTest
• :app:assembleDevelopDebug
• detektAll
• Pixel checks for online refresh, offline use of saved data, and a controlled changed course-structure response
• Android lint ran and reported only documented pre-existing issues in unrelated files

AI Assistance

AI tools were used to aid diagnosis, planning, implementation, testing, and review. All work was checked and reviewed.

[openedx-webhooks]

Thanks for the pull request, @edschema!

This repository is currently maintained by @openedx/openedx-mobile-maintainers.

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.