First some background: I'm working on an iOS app called DiscoCat that uses the MusicBrainz API. On the artist page, the user can open up a section to show the discograpy (official releases only) and when they do that it makes a series of paged search calls (in sequence but right after each other) to find all the release groups containing official releases for a given artist ID. So for the Pixies for example, it makes the following 2 calls to get all 117 release groups (with Accept headers set to return JSON responses):

https://musicbrainz.org/ws/2/release-group?fmt=json&query=arid:b6b2bb8d-54a9-491f-9607-7b546023b433%20AND%20status:official&limit=100&offset=0

https://musicbrainz.org/ws/2/release-group?fmt=json&query=arid:b6b2bb8d-54a9-491f-9607-7b546023b433%20AND%20status:official&limit=100&offset=100

I use those search calls instead of doing a browse for all release groups since there is no way to specify official only releases on a browse release group call and I want to minimize the API calls and network data returned as well as the amount of JSON data the app has to parse through to filter out the official release groups.

So enough background, here is the bug: Sometimes I notice there are release groups missing and the order is not always consistant in the paged results between identical requests within seconds of each other. At first I thought this might be do to URL caching of older pages mixed with newer ones on the app side so I made sure URL caching was turned off for paged requests. I'm still seeing it though so I isolated it to the raw requests in Paw (a mac app similar to Postman and curl) and I was able to reproduce it just using Paw (as well as curl) and I've attached the results of both pages for the good case and the bad. Search for the release group ID "ac9b0a0c-0da6-387f-8c09-65783187346a" (Pixies' Trompe le Monde release). You should find it in the first page of the good response but not in either page of the bad response.

Oh by the way, I included the response headers as well as the first part of those files (so the files are not pure JSON until you remove those).

You may find other release groups missing in the bad responses as well. Since the total release group count is the same (117) for both the good and bad responses, my guess is there are duplicated release-groups in the other page to make the counts the same but I haven't confirmed that yet.

If you try to reproduce it yourself, keep in mind that it only happens occasionally so you may have to try a few times before you notice missing release-groups. I've never noticed any missing release-groups when there is just one page of results, so it might have to do with caching of pages on the server but that is just my guess. This theory would also explain any duplicate release-groups as well.