Snapper post‑upgrade snapshot retention after manual rollback in openSUSE Leap

When a zypper dup upgrade fails on openSUSE Leap, Snapper creates a pre‑upgrade snapshot that can be rolled back and leaves the failed post‑upgrade snapshot intact for inspection. The release notes note an unresolved decision about whether this failed post‑upgrade snapshot should be automatically removed after a successful manual rollback, leaving the action to the administrator’s discretion.

The goal is to clarify the expected cleanup behavior to avoid uncontrolled Btrfs space consumption while preserving the ability to diagnose upgrade failures. Constraints include limited disk space on the root subvolume, the need for manual intervention in current implementations, and the lack of a defined policy in the documentation.

Should Snapper automatically delete the failed post‑upgrade snapshot after a successful rollback? What conditions should trigger automatic pruning, and how would this impact troubleshooting and space management?