[BobbyESP]

The crash

IllegalArgumentException: Key "candidate:musicbrainz:ab7be9dd-9ac8-4796-a5b8-b605db62d7f5/b5fe1a0e-a06c-4c81-afaa-ae6f93cc992c" was already used.
If you are using LazyColumn/Row please make sure you provide a unique key for each item.

Thrown by SubcomposeLayout while the lookup sheet's LazyColumn measures (LookupSheet.kt, candidates keyed by ItemKey.of("candidate", providerId, id)).

Root cause

MusicBrainzProvider.toCandidates() builds one candidate per release, with id "$recording/$release". MusicBrainz's recording search lists a release once per medium the recording is on. Checked against the live API for the recording in the report:

release	medium	format	track
b5fe1a0e… LANDSPACE (LiSA)	2	Blu-ray	7
b5fe1a0e… LANDSPACE (LiSA)	3	DVD-Video	7

Two candidates, one id, so two items with one key. Any deluxe edition, box set or CD+DVD release with the song on more than one disc triggers it. Nothing between the provider and the list removed repeats.

v2.0.1's ItemKey.of stopped different candidates from sharing a key by escaping separators. It could not help here, because these two candidates have the same id.

Why Crashlytics mixes albums and candidates

The exception is thrown during layout. No app frame is on the stack, so Crashlytics groups every duplicate-key crash in the app into one issue. Only the message tells them apart:

• album:<id>:<Title>: v2.0.0's album keys, fixed in v2.0.1 by f287f63. Album keys are now the groupBy key itself, so they can't repeat.
• candidate:musicbrainz:… (or musicbrainz… without separators in v2.0.0): this bug, present in 2.0.0 and 2.0.1.

Filter the issue by version 2.0.1. Every event left should be a candidate: key.

Audit of every data-keyed lazy list

List	Key	Unique?
Songs, collection songs	MediaStore _ID (primary key, one query)	Yes
Albums / artists / folders	ItemKey of the groupBy key	Yes, by construction
Lookup candidates	provider + id	No, fixed here
Lookup field proposals	tag key from a map	Yes
Editor fields / raw tags	static field keys / keys of a map, minus known ones	Yes
Queue	id + index	Yes
Lyrics	index	Yes
History (unreleased)	Room ids, grouped by day	Yes

Navigation 3 also uses SaveableStateHolder ("Key … was used multiple times"). Navigator.goTo only skips a key already on top, so on a wide window the same Editor(uri) can be on the stack twice. Navigation 3 1.2.0 is built for that (entries with the same contentKey share state, and SceneSetupNavEntryDecorator renders each key in one scene only), so it is not a crash source today.

The fix

1. MusicBrainzProvider: one entry per release (distinctBy { it.id }), keeping the lowest disc. This also stops a repeated release from taking one of the three release slots per recording.
2. LookupService: candidates are made distinct by (providerId, id) where every provider's results come together. This is the only way candidates reach the sheet, so no provider can crash the list, Deezer included. Deezer replaces its top hits with /track/{id} details, which could plausibly resolve two hits to one track. That is not verified against the API.

Cost: one distinctBy over at most about 35 items per search, once.

Tests

• MusicBrainzProviderTest: the LANDSPACE response shape gives one candidate per release, from disc 2.
• LookupTest: a candidate a provider repeats is listed once.

Both fail on master (v2.0.1) and pass with the fix. ./gradlew test spotlessCheck is green.

Not done (options)

• Safety net in the UI: give a repeated key a suffix (#2) in the list. It would stop any future repeat from crashing, but it also hides the data bug. The domain guarantee and its test are the better layer.
• Traceability: in the playstore flavor, set a Crashlytics custom key with the top destination. Layout crashes would then say where they happened.

🤖 Generated with Claude Code