storefront UI metadata updates are not protected by metadata conflict handling

[Martin Wimpress ]

We have noticed that periodically the metadata of snaps that are hooked up to build.snapcraft.io are being reset to what the snapcraft.yaml defines.

For example, the metadata has been manually updated for ffmpeg, vscode and tmnationsforever their respective https://snapcraft.io/account/snaps/<snapname>/listing page.

At some point, the following fields are reset to what the snapcraft.yaml defines destroying what may have been manually entered:

  * title
  * icon
  * summary
  * description
  * license

[Daniel Manrique (roadmr)]

Hello,

I've determined that it's not build.snapcraft.io that's doing this; I was able to reproduce this problem just with snapcraft and a locally built snap.

(However - the snap was registered and initially uploaded with build.snapcraft.io - it would be very weird for b.s.io to be leaving things in a crappy state that then allows the following to happen, but let's not discard the possibility).

steps to repro:
- register a snap
- create a snapcraft.yaml with a description and summary nicely written.
- build, push with snapcraft
- confirm in snapcraft.io/account/snaps/thesnap that the metadata is ok
- confirm in dashboard.snapcraft.io/snaps/thesnap that metadata is ok
- confirm in snap info thesnap that metadata is ok

- in snapcraft.io/account/snaps/thesnap modify the metadata
    - update summary
    - update description
    - set an icon

- rebuild the snap (change the version but not the metadata in the yaml)
- snapcraft push thesnap-whatever.snap
- snapcraft doesn't say anything about metadata:

$ snapcraft push thesnap_2018-07-20-04_amd64.snap
Pushing thesnap_2018-07-20-04_amd64.snap
Preparing to push '/home/ubuntu/thesnap/thesnap_2018-07-20-04_amd64.snap' to the store.
Pushing delta /home/ubuntu/thesnap/thesnap_2018-07-20-04_amd64.snap.xdelta3.
Pushing thesnap_2018-07-20-04_amd64.snap.xdelta3 [================================================] 100%
Ready to release!
Revision 10 of 'thesnap' created.

WHat should happen:
- snap info, dashboard and snapcraft.io/store all show the manually-updated metadata, because since there was a conflict, snapcraft should NOT have updated metadata from the snapcraft.yaml.

What actually happens:

- snap info shows the metadata we'd set manually earlier didn't change (https://dashboard.snapcraft.io/snaps/thesnap/)
- the public storefront page also shows the correct manually-edited metadata.
HOWEVER:
- reloading https://snapcraft.io/account/snaps/thesnap/listing shows the data was clobbered / reoverwritten with what the snap.yaml had
- dashboard was also reset
- icon disappeared from dashboard and storefront

[Daniel Manrique (roadmr)]

Only updates made in dashboard.snapcraft.io count as "manual" updates, and are "protected" from snapcraft overwriting them by the conflict mechanism.

So if a snap never has their metadata updated via dashboard.snapcraft.io, the other two options (snapcraft command itself and https://snapcraft.io/account/snaps/) *will* conflict with each other, and the last one to be run will win and overwrite the metadata.

For now, the workaround is to do all manual metadata edits via dashboard.snapcraft.io; barring that, please ensure the snapcraft.yaml is up to date and contains the desired metadata so snapcraft can push the proper values.

However, there *are* two bugs here. The first is that updates done by hand via https://snapcraft.io/account/snaps/ do NOT count as "manual edits", which they should. The proposed solution is to add a flag or indication to the metadata API as to whether the update was manual, and have https://snapcraft.io/account/snaps/ set that flag, so edits done there "trump" automated tools like snapcraft (which would presumably not set the flag).

The second is that, as seen in my repro case, apparently under certain circumstances snapcraft metadata pushes are not propagating properly to snapident (though they are acknowledged in dashboard), which explains why https://snapcraft.io/account/snaps/ and dashboard (which use the developer APIs) do show the updated data, but the public storefront (snapcraft.io/snap-name) and snap info don't (because they use the device-level APIs which hit snapident). This one, I'll report separately.

[Matias Bordese (matiasb)]

A possible approach would be to add an extra parameter to the metadata API allowing the requester to mark the pushed changes as "check for conflicts on future updates to these"; that is, in a next call to the update metadata API, if the changes being pushed conflict with the previous update, raise a metadata conflict to the client (unless the forced update flag is given).

In that way, every change through the dashboard UI will be marked for future conflicts check, and every update set through the API with the above param, too (for example, the storefront updates through the API should use this param).