So I’m checking out if linked recordings are correct, in this release and for some reason there is 5 random tracks in the middle of the tracklist linked to one recording.
In the history I found my edit which was releases merge and what is baffling for me is that in this edit with the merge of releases, 5 random tracks were merged into one as well.
How that could happend?
Computers are really efficient at making a mess… 
The important thing is the human has spotted it.
Without reading 16 pages of edits it is hard to work out what actually happened. Maybe someone did a merge on AcoustIDs. Or just a plain slip of the mouse. Trouble is with smaller artists there are not many eyes on the edits to catch a mistake like that.
And for the biggest artists, there are too many edits to keep track of
I couldn’t be arsed to look at all those edits myself either, so I let an AI tool do the work.
The unexpected merge in Edit #147769155 happened due to a combination of an off-by-one tracklist mismatch between the two releases, a prior recording merge, and the transitive merge-target resolution logic in MusicBrainz Server.
When merging the two 39-track releases:
4556252, added in Edit #115717678):
5629823, added in Edit #143113063):
Because both releases had exactly 39 tracks, tracks 8 to 11 were shifted by 1 position:
| Pos | Destination Release (4556252) Track & Rec ID |
Source Release (5629823) Track & Rec ID |
|---|---|---|
| 8 | Laissez‐moi tranquille (22422261) |
Mi Gna (22275655) |
| 9 | Mi Gna (remix) (22275655) |
Tu reviendras (22422262) |
| 10 | Tu reviendras (22422262) |
Nos valeurs (22422263) |
| 11 | Nos valeurs (22422263) |
Tu ne le vois pas (originally 22422264, see below) |
| 12 | Merci maman (38590238) |
Merci maman (38590238) |
| 13 | T’es partie (22422266) |
T’es partie (22422266) |
In Edit #143113178, editor maggielou merged recording 22422264 into 38590238 (“Merci maman”).
When that edit applied, all tracks pointing to 22422264 were redirected to 38590238. As a result:
38590238.38590238.newr.id == oldr.id at track 12 (38590238 == 38590238), track 12 was excluded from the merge candidates (WHERE newr.id != oldr.id), and track 13 onward were already identical.When selecting the strategy “Merge mediums and recordings” (merge_strategy = "2"), MusicBrainz runs determine_recording_merges in MusicBrainz::Server::Data::Release:
Candidate query: It matches tracks sharing the same position where newr.id != oldr.id:
22422261 (Laissez‐moi tranquille), Source = 22275655 (Mi Gna)22275655 (Mi Gna), Source = 22422262 (Tu reviendras)22422262 (Tu reviendras), Source = 22422263 (Nos valeurs)22422263 (Nos valeurs), Source = 38590238 (Merci maman)Chaining logic (MBS-8614):
To prevent intermediate recordings from being merged into deleted sources (e.g. 1 -> 2 and 3 -> 1), MusicBrainz traces target:
my $target = $merge_targets{$new_recording->{id}} // $new_recording;
22422261. Source 22275655 is assigned to target 22422261. It sets $merge_targets{22275655} = 22422261.22275655. The server checks %merge_targets, sees 22275655 was mapped to 22422261, and redirects the target to 22422261. Source 22422262 is now added to 22422261, and $merge_targets{22422262} = 22422261.22422262, which is redirected to 22422261. Source 22422263 is added to 22422261.22422263, which is redirected to 22422261. Source 38590238 is added to 22422261.Because each track in positions 8–11 on the destination release had the same recording as the preceding track on the source release, the transitive merge resolution chained them all together. Rather than creating 4 separate positional merges (or failing), the algorithm collapsed the entire 4-track domino sequence into the root target at track 8: “Laissez-moi tranquille”.