Channel_maps_list is empty when using /v1/snaps/search as opposed to using /v2/snaps/details

store
1

If found that snapd would return channel information when using /v2/find?name=moon-buggy but not when using /v2/find?q=moon-buggy. It appears this is due the store returning the channel information on one endpoint (/v1/snaps/details) and not another (/v1/snaps/find).

Can /v1/snaps/find be modified to return the channel information?

$ curl 'https://api.snapcraft.io/api/v1/snaps/details/moon-buggy?fields=channel_maps_list' -H "accept: application/hal+json" -H "X-Ubuntu-Release: 16" -H "X-Ubuntu-Device-Channel: edge" -H "X-Ubuntu-Wire-Protocol: 1" -H "X-Ubuntu-Architecture: amd64"|jq

{
  "channel_maps_list": [
    {
      "architecture": "amd64",
      "map": [
        {
          "binary_filesize": 90112,
          "channel": "stable",
          "confinement": "strict",
          "epoch": "0",
          "info": "released",
          "revision": 12,
          "version": "1.0.51.11"
        },
        {
          "channel": "candidate",
          "info": null
        },
        {
          "channel": "beta",
          "info": null
        },
        {
          "channel": "edge",
          "info": null
        }
      ],
      "track": "latest"
    }
  ],
  "package_name": "moon-buggy"
}

$ curl 'https://api.snapcraft.io/api/v1/snaps/search?name=moon-buggy&fields=channel_maps_list' -H "accept: application/hal+json" -H "X-Ubuntu-Release: 16" -H "X-Ubuntu-Device-Channel: edge" -H "X-Ubuntu-Wire-Protocol: 1" -H "X-Ubuntu-Architecture: amd64"|jq

{
  "_embedded": {
    "clickindex:package": [
      {
        "channel_maps_list": [],
        "package_name": "moon-buggy"
      }
    ]
  },
  "_links": {
    "self": {
      "href": "http://api.snapcraft.io/api/v1/snaps/search?name=moon-buggy&fields=channel_maps_list"
    }
  }
}
2

Can you explain why you need it?

1 Like
3

When you search in GNOME software for snaps, we cache that information when you click through for details to install. We’d have to do a second round-trip to the server to get the channel information otherwise.

Since snapd uses the same endpoint for both these store methods, as a client I assume the results would be the same regardless if you use /v2/find?q= or /v2/find?name=. So unless there’s a performance cost I think we should keep that consistency.

4

AIUI it’s an expensive thing to build, yeah.

5

Building channel_maps_list for all search results would be imposing performance penalties on searches which would rarely pay off. Also because of the implications of refresh-control (validations), I would rather not cache that information on clients either.

However let us know how the additional round-trip is affecting the whole GS experience. We should be exploring ways to improve overall API performance.

6