If snapd is unable to contact the store, there’s nothing that can be done store-side to help with this issue.
I checked with the snap core team and was told that simply installing snapd (e.g. from a deb) doesn’t cause it to automatically install seeded snaps; so the request to install those snaps (and the failure to do so) comes from somewhere else, and means it’s also not behavior that can be altered in snapd itself.
Snap core team also helped pinpoint the source: it’s do-release-upgrade (actually the python3-distupgrade package) that does this. It contains a DistUpgrade.DistUpgradeQuirks module that has a _replaceDebsWithSnaps method, it’s the one that actually does
snap install foo:
Trivially, making the “snaps” list in that method empty would cause not to install anything. However, I notice the code is supposed to not exit with a failure code when it fails to install a snap (see how it catches CalledProcessError and just logs the problem and
continues ). So it probably needs more thorough analysis to see if it’s failing at another point, and either fixing this upstream in
python3-distupgrade or crafting a fixed, custom version and distributing that to the systems you want to upgrade in a disconnected environment.