Here's another 100-disc one reported as sporadically failing: http://musicbrainz.org/release/b8ed94c7-4858-4081-92d6-31f1a9de4c64

The same happens on the web service with such releases.

Another one: http://musicbrainz.org/release/9c5c043e-bc69-4edb-81a4-1aaf9c81e6dc

I guess this is related to the latest changes that relationships are displayed on the release page. http://musicbrainz.org/release/9c5c043e-bc69-4edb-81a4-1aaf9c81e6dc has 80 discs where each recording has many relationships. Picard cannot open it either if options include to load ARs. It can load it however if the option to load ARs is disabled.

The Picard issue is a separate one that's pre-existing, but yes - the option to display ARs does not perform well enough to be enabled IMO; it has made some releases completely inaccessible/uneditable....

Can anyone join in? http://musicbrainz.org/release/88eb1012-a181-325c-bd6e-2cdc9b4b5414

Setting due date based on when this ticket entered this milestone

Just checking if there was any status that could be shared on this issue?

just wanted to report that I was able to enter http://musicbrainz.org/release/d572e17d-10ef-47f1-bd39-9d1406a252d0 (150 Medium), http://musicbrainz.org/release/8a4365ca-02ca-49e2-af3c-676eac91018c (99 medium), but not the 100 Medium releases linked in other comments.

I am sadly out of ideas on this again, so I'm moving back to decision required so it is out of my work queue.

It releases depends on what you are including, i.e this one is fine even if you include recordings

http://musicbrainz.org/ws/2/release/88eb1012-a181-325c-bd6e-2cdc9b4b5414?inc=recordings

I think most problems are caused by introduction of

work-level-rels
tags

which can cause massive duplication, and implementatation hasnt be well thought out

http://musicbrainz.org/release/cf74e971-b791-4c23-ab2d-2189e6f8195a has fallen victim to this.

This issue really deserves attention because it is close to being a show-stopper. The only known (to me) workaround is to create a set of smaller pseudo-releases. I understand there are design issues and the solution may take a lot of effort, but this is not just a nice-to-have.

Could there be a solution akin to what happens in the release editor for releases with a large number of media? So that when you intially browse the relase, the media are "closed", and the requests for the relationship data only get sent when you "open" a medium?

Attempted mock-up of monxton's suggestion. (Somehow browser refuses to load Java, so can't upload as screenshot).

However, if such lazy loading is deployed, quite many userscripts will need to be rewritten to trigger on clicking of track lists since track data is not preloaded.

Question on how to edit such massive releases probably warrant a new ticket. I don't have idea about how to do that yet.

Looks like even more serious now. This 10 CD release also fails:

http://musicbrainz.org/release/bb0a0e13-9393-4e5f-af82-3c254e2889b5

The following procedure describes step to reliably reproduce 502 error:

1. Edit the release
2. Under tracklist tab, expand Disc 2
3. Remove all performer credits for all tracks which are enclosed in parenthesis
4. Click 'Next'
5. 502 Bad Gateway

Looks like this 2CD release, with 36 tracks, also fails:
http://musicbrainz.org/release/409f2788-d305-4508-b12d-cb236e8c0b35

It's classical music, so lots of relationships I guess.

Musicbrainz is going to be pretty useless for classical music if this bug isn't solved

If a Tracklist was a first-class editable object it wouldn't be essential to open the whole release.

Xavier, that's a 90xCD! http://musicbrainz.org/release-group/d18a598a-ad06-4fa2-b567-3a463c3bad13

Oh, my bad. I was using picard to tag a 2cd album of Yo-Yo Ma, and it looks like it picked the whole lifetime compilation instead