'snap refresh' with non-existent gives misleading error string

Just an FYI for someone who can correct the error string for following scenario.

tm snap in my brand store does not have rev17. Made a typo while refreshing. But IMO the error that I got does not indicate correct reason.

dev@dhcppc4:~# snap refresh tm --revision=17
error: cannot refresh "tm": Access by specifying a revision is not allowed for this Snap.

Instead should have got, revision 17 does not exist

When tried with revision that exists, it succeeded

dev@dhcppc4:~# snap refresh tm --revision=3
tm (beta) 0.0.0.7 from IoT Administrator (xyz) refreshed
root@dhcppc4:~#

Hi, can you file a bug for this on bugs.launchpad.net/snapd ?

That error message comes from the store, so it’s not a snapd bug. But I don’t think it’s a store bug either, since the code is very clear: only the snap’s publisher or one of its collaborators can download a snap from the store by revision, not just a device on its brand store.

It looks to me like you already had r3 locally, so refresh didn’t actually need to hit the store. You can probably confirm this by checking the mtime on /var/lib/snapd/snaps/tm_3.snap.

Device I am running from is logged in with same account as that of brand store.

Unfortunately, I moved on other tests and have flashed a complete new image.

It needs to be an account which can manage the snap, not just the store.

Yes it is an account that can manage snaps

Are you completely sure? Does snap whoami in the same context show the correct iotadmin account? The store code is clear, and my tests show it working as expected:

$ snap refresh wgrant-test --revision=100
error: snap "wgrant-test" revision 100 not available (see 'snap info wgrant-test')

Yes.

The ‘Ubuntu One email’ on OpenID transaction in progress and snap whoami matches.

The ‘Snap account-id’ on OpenID transaction in progress and user in /var/lib/extrausers/passwd matches.

snapd records the user that installed each snap, so that in the case of a private snap it can use the right credentials during refresh. I wonder if that’s what’s happening here, causing it to not use the credentials of the currently logged in user during refresh.

Unfortunately I don’t know exactly how those bits of snapd work, so I’ll have to leave this to the snapd developers.