I have noticed that the recent release candidate builds of snapd 2.30 seem to contain changes to the REST API. In particular I’m using https://github.com/snapcore/snapd/wiki/REST-API#post-v2snaps to get details about snaps installed on systems.
It appears that this PR https://github.com/snapcore/snapd/pull/4260 resulted in fields that are empty being omitted from the returned data. My code currently doesn’t handle this situation.
@robert.ancell could you comment on whether this change is really necessary?
If it is decided to keep the change could it be communicated appropriately so that we have chance to modify code?
Sorry about that @joc - I didn’t consider other clients aside from the command line tool and snapd-glib. Both these clients handle any fields missing and have default values. @chipaca - do you think that’s a reasonable assumption? I can update the REST docs if that’s the case.
@joc - which fields are causing the issue for you? Is it hard to update your tools?
What would be the best way to communicate a change like this? On this forum?
There’s one change that I think is very important - making the install-date optional. This is because it gets sent as 0001-01-01T00:00:00Z if unset, which is (technically) a valid date.
This structure is used for both snaps returned from /v2/find and /v2/snaps - many of the fields only make sense in one of those. So omitting them makes it much easier to understand.
The remaining fields are just unlikely to be set and make the output noisy.
I think the specific field that caused the issue in this case was devmode, although I assume there were several others that might have caused a problem.
For the record these tools are specifically to test releases prior to promotion so we caught them early. If anyone else is using this API in the naive way I am, they could have breakages of stable devices.
I pushed https://github.com/snapcore/snapd/pull/4379 that restores all the boolean fields. This should fix the use-case of @joc and I think it generally makes sense to have the true/false answer for those.
