zypper rollback behavior when repository list changes after a failed upgrade

Short answer

There is no zypper rollback command, so the premise needs unpacking first. Rollback on openSUSE/SLE systems is performed by snapper (btrfs snapshots) or transactional-update (MicroOS / SLE Micro), and zypper is only invoked inside those environments. Neither tool treats the repository list as a separately versioned artifact, and neither warns when the active repo set has drifted since the failed transaction. The repository definitions are captured only implicitly, as files inside the filesystem snapshot.

What is confirmed vs. what is likely

Confirmed behavior: snapper rollback restores the root subvolume to the snapshot taken before the transaction. Because /etc/zypp/repos.d normally lives on that subvolume, the repo definitions revert to whatever existed at snapshot time. Any repo you added, removed, or re-pointed after the failed upgrade silently disappears from the rolled-back system.

Likely, but verify on your version: during a transactional-update repair or rollback run, package resolution uses the repo configuration visible inside the snapshot environment, not your current live configuration. The exact inclusion of /etc/zypp in snapshots depends on the subvolume layout, which has changed across openSUSE releases — treat this as version-sensitive and confirm against the installed man snapper and man transactional-update.

Answers to the three design questions

1. Should zypper automatically use the repo list recorded at transaction start? It effectively already does — but only as a side effect of the filesystem snapshot, not as a deliberate mechanism. There is no distinct "repo list artifact" stored per transaction.
2. Should it warn when the active list differs? That would be a sensible enhancement, but no such warning exists today. It would need to be filed against zypper or snapper as a feature request.
3. Should an explicit flag be required to override the original set? Again a reasonable proposal, not an existing feature. Today the override is implicit: whatever is in the snapshot wins, with no prompt.

Safe recovery path for this case

Until such a warning exists, the practical rule is: do not modify repositories between a failed upgrade and the rollback. If you already did, verify the state inside the recovery environment before letting it resolve packages:

# Before rollback: record what you changed
zypper lr -d > /root/repos-before-rollback.txt

# After booting the rolled-back snapshot, compare
zypper lr -d
diff /root/repos-before-rollback.txt <(zypper lr -d)

To confirm what a snapshot actually captured:

snapper list
snapper status 12..13   # pre/post pair of the failed transaction
ls /.snapshots/<N>/snapshot/etc/zypp/repos.d/

Best verified in a disposable VM: start an upgrade, edit a repo, let it fail, roll back, and inspect which repo set package resolution uses. One detail that changes the recommendation: are you on a traditional btrfs+snapper install or transactional-update (MicroOS/SLE Micro)? The semantics differ enough that the recovery steps should be tailored to which one you run.