Can DNF treat a total mirror failure as an implicit cache invalidation signal on Rocky Linux?

Rocky Linux repositories rely on DNF's local metadata cache in /var/cache/dnf, governed by the metadata_expire interval. When every mirror in a repository's mirrorlist becomes unreachable, DNF falls back to the next mirror; if all fail, it retains the existing stale cache unless the expiration interval has already elapsed. The core uncertainty is whether a complete mirror failure should act as an implicit signal to invalidate that cache immediately, or whether the timer alone should control refresh attempts.

This behavior is not standardized uniformly across Rocky Linux releases. Rocky Linux 8 ships with DNF 4, while Rocky Linux 9 uses DNF 5, and their metadata handling plugins differ. Custom repository configurations that override metadata_expire or enable mirrorlist_expire can further change the outcome. Because the decision point between stale-cache reuse and forced refresh remains configurable but not uniformly defined, administrators need to confirm the exact behavior on their specific release and repository configuration.

Which policy governs stale-cache retention after a total mirrorlist failure in Rocky Linux 9? Does the mirrorlist_expire setting alter the decision to reuse cached metadata when no mirror is reachable? When should an operator expect DNF to serve stale data versus refusing the transaction?