Stale DNF metadata cache in Rocky Linux: diagnosing repodata freshness and expiry defaults

Rocky Linux ships DNF (DNF4 on releases 8 and 9) with per-repository metadata cached on disk, and that cache can go stale relative to mirror content. The symptom pattern needing diagnosis: package lookups or downloads can fail with HTTP 404 errors or metadata download failures when cached repomd or primary data still references package files or checksums a mirror has since pruned or replaced, for example during a point-release sync.

Two factors complicate the picture. Rocky content is spread across many mirrors with varying sync lag, and DNF selects a mirror without cross-mirror consistency checks, so a stale cache combined with a lagging mirror can produce intermittent, non-deterministic failures that resemble flaky infrastructure. Separately, Rocky's shipped .repo files generally leave expiry to DNF's compiled default rather than pinning metadata_expire per repository, so the effective cache lifetime can shift with DNF defaults across major versions; defaults also differ between DNF4 and DNF5.

Assuming Rocky 8/9-era DNF4 behavior, three questions need resolution:

1. What is the authoritative metadata_expire default for DNF4 on Rocky 8/9, and how is it confirmed on an installed system?
2. Should metadata_expire be pinned per repository in /etc/yum.repos.d to balance freshness against mirror load, or left to DNF defaults?
3. Can genuinely stale cached repodata be distinguished from transient mirror sync lag when failures are intermittent?