Problem Statement

In Red Hat Satellite Capsules with "Immediate" sync mode, during the synchronization of content views (which occurs every Saturday and takes several hours), the metadata (repodata) on the Capsules becomes inconsistent with the available packages. Specifically, the metadata is sometimes published or regenerated before the corresponding RPMs are fully downloaded/written to the Capsule's storage.
This leads to yum/dnf dependency errors on client systems (e.g., "requires X but none of the providers can be installed") because the client sees the new metadata but cannot retrieve the referenced package files. This effectively creates a denial of service for patching operations during the entire synchronization window.

User Experience & Workflow
Current Behavior:

• A Content View is promoted on Satellite.
• Capsule synchronization starts (Immediate mode).
• A client system runs yum update.

The client fails with dependency errors because the Capsule provides metadata for packages it does not yet have fully on disk.

Desired Behavior (Two potential technical approaches proposed):

Approach A (Fallback): If a Capsule is missing a package requested by a client (but the package exists in the metadata), the Capsule should automatically fall back to the central Satellite server to fetch the content on demand.

Approach B (Sync Logic): The Capsule synchronization logic should be reversed or guarded: ensure all content (RPMs) is fully downloaded and committed to the Capsule's storage before the new metadata/repodata is generated and exposed to clients.

End State: Clients can successfully install or update packages at any time, even while the Capsule is actively synchronizing a new Content View.

Requirements

Consistency Guarantee: The Satellite/Capsule architecture must ensure that a client never receives metadata referring to content that is not yet retrievable from that Capsule.

Fallback Mechanism (Preferred): Introduce a setting allowing Capsules in "Immediate" mode to fall back to the parent Satellite server for content retrieval if a file is missing locally during a sync.

Sync Order (Alternative): Alternatively, modify the synchronization workflow so that Repodata is only regenerated/published after the artifact synchronization is 100% complete.