cPanel upcp upgrade died mid-transaction: re-run with --force or restore the pre-upgrade snapshot?

A cPanel & WHM upgrade run via /scripts/upcp stopped partway through, leaving the server in a partially updated state. The most recent timestamped log under /var/cpanel/updatelogs/ shows the run never reached its final stage, and the failure appears tied to the OS package layer (a yum/dnf transaction problem) rather than to cPanel itself.

The documented constraints narrow the options. cPanel does not support downgrading to an earlier major version, so there is no built-in undo. Re-running /scripts/upcp --force is designed to resume and complete a partial update, but only after the root cause is fixed and no stale update lock or concurrent upcp process remains. Restoring a snapshot is only valid if it predates the upgrade attempt, since a mid-upgrade snapshot can reintroduce inconsistent package state.

What is unclear is the decision point itself: cPanel provides no automated way to judge whether the partial state is cleanly recoverable by forcing upcp again, or whether package-level corruption has gone far enough that the pre-upgrade snapshot is the safer path.

Assume a current cPanel & WHM LTS tier on AlmaLinux; exact paths and behavior should be confirmed against the installed version's documentation.

Questions

• What in the updatelogs output or the rpm database state reliably distinguishes a resumable partial update from corruption that justifies a snapshot restore?
• If the yum/dnf transaction is repaired first, does a forced upcp re-run reconcile half-installed cPanel packages, or can version mismatches persist silently?
• Is there any supported validation step after recovery beyond checking /usr/local/cpanel/cpanel -V and core services?