Moodle MUC and Redis: Fallback behavior when Redis store fails

Goal

Determine how Moodle’s Universal Cache (MUC) behaves when a configured Redis store becomes unavailable on a low‑traffic, single‑server deployment.

Constraints and uncertainty

The site runs Moodle 4.x with MUC configured to use Redis as the primary cache backend and the default file store as a secondary backend. The server has limited RAM and CPU, so any automatic cache rebuild must be predictable. Documentation describes store priorities but does not explicitly state whether MUC silently fails over or raises an exception when the primary store is unreachable.

Questions

1. What is the documented fallback order when a Redis store becomes unreachable?
2. Does the cache API surface an error to the application or silently degrade to the next store?
3. How can an administrator verify the active store at runtime without triggering a full cache purge?