Snap Nextcloud error to refresh from 17 to 18 (404 not found the download link)

I am currently using snap nextcloud 17/stable version, and want to upgrade to 22/stable.

But when I try to refresh nextcloud to 18/stable, it shows below error:

I check the link, seems it is unreachable.

I tried to download 19/stable and others, they are ok.

Any solution of this?

The above link shows:

410 Gone

nginx/1.14.0 (Ubuntu)

The download links have a time-expiring token, so if you try to download the same exact link after a certain period, it will indeed be 410.

Does the snap refresh process still say the same thing if you retry?

@roadmr Hi, yes I retry both refresh and download, but none of them is work.

I can confirm. First of all, note that there IS something released there:

$ snapcraft status nextcloud --track=18
Track    Arch     Channel    Version        Revision
18       amd64    stable     18.0.12snap1   25109
                  candidate  ↑              ↑
                  beta       ↑              ↑
                  edge       18-2021-05-15  27832
         arm64    stable     18.0.12snap1   25110
                  candidate  ↑              ↑
                  beta       ↑              ↑
                  edge       18-2021-05-15  27838
         armhf    stable     18.0.12snap1   25111
                  candidate  ↑              ↑
                  beta       ↑              ↑
                  edge       18-2021-05-15  27843
         i386     stable     18.0.12snap1   25107
                  candidate  ↑              ↑
                  beta       ↑              ↑
                  edge       18-2021-05-15  27834
         ppc64el  stable     18.0.12snap1   25108
                  candidate  ↑              ↑
                  beta       ↑              ↑
                  edge       18-2021-05-14  27812

But it’s uninstallable:

$ sudo snap install nextcloud --channel=18
error: cannot perform the following tasks:
- Download snap "nextcloud" (25109) from channel "18" (received an unexpected http response code (404) when trying to download

I’m on amd64 here, as you can see. Easy to test for yourself, @roadmr.

Hey folks,

This is working now:

$ curl -LO
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   571  100   571    0     0    981      0 --:--:-- --:--:-- --:--:--   979
  5  252M    5 13.9M    0     0  2764k      0  0:01:33  0:00:05  0:01:28 3682k

(I didn’t download the full thing but it’s happily sending it my way now).

Confirmed, works for me as well. Thanks for fixing it! What ended up being the problem?

The missing revisions were an unintended consequence of preparation for an upcoming retention policy change.

With more and more snaps providing daily edge builds, it’s neither practical nor useful for the Snap Store to keep them forever – nextcloud alone has many terabytes of them, and they’re practically never accessed on subsequent days. So we’re working on preliminary policy changes to expire old daily builds (e.g. only ever in edge and superseded more than six months ago), and nextcloud was a test case for the new rules, but a few stable revisions ended up erroneously unavailable too. We’ve made them all visible again.

Ah ha, yes that makes sense. Edge builds are rarely useful once they’re no longer the latest in a channel (rarely == never for me). I do find myself fetching old stable revisions though from time to time, even if they’re not the latest in the channel. I know you said you’re only looking to do this for revs released to edge, I just wanted to throw that out there as you potentially consider expanding.

1 Like

Thanks for the information on your usage. The proposed criteria (only ever in edge, and not the current revision in the last six months) recover >85% of the space consumed by daily-heavy snaps like nextcloud, so they’re what we’re testing for now.

I don’t see an immediate need to prune old stable revisions, but that set obviously also does grow without bound over time, albeit much more slowly, so we’ll probably need to eventually bring in a policy there too.

It works for me now as well. Thanks folks!

Agreed. Generally my use-case is someone who didn’t auto-update for ages for whatever reason and then ran into an issue updating to the latest that I want to try and duplicate. I have only deep-dived years back into stable revisions once, and it was to release some of them into new tracks so I could have a better history. If we ignore that outlier, I think for my use-case if you bump the timespan out a year or two for stable revisions that will work just fine. Heck even if you started at 5 years you’d have a bound.

1 Like

Thanks for the feedback @kyrofa. We are working on formalizing a policy and will add that to public documentation when ready. We will definitely start out pretty conservatively and would love to hear from others if there are any concerns with the initial “only ever edge, 6mo+ back” approach. We can post separately with an appropriate title when we get closer to finalizing the policy and implementing a larger/regular pruning.