Beet Import Crash: AttributeError

[scottia]

Problem: 2.10.0 regression from 2.9.0 — import crash (TrackInfo.raw_data missing)

Running this command in verbose (-v) mode:

$ beet -v import -I "/<path>/<album>"

Leads to the following crash:

Sending event: import_task_choice
Traceback (most recent call last):
  File "/lsiopy/bin/beet", line 6, in <module>
    sys.exit(main())
             ^^^^^^
  ...
  File "/lsiopy/lib/python3.12/site-packages/beets/autotag/hooks.py", line 492, in merge_with_album
    raw_track = self.raw_data
                ^^^^^^^^^^^^^
  File "/lsiopy/lib/python3.12/site-packages/beets/autotag/hooks.py", line 123, in __getattr__
    raise AttributeError(
AttributeError: 'TrackInfo' object has no attribute 'raw_data'

The album is successfully matched (100% / Distance: 0.00) before the crash, so the failure occurs during metadata application after selecting the match.

Setup

• OS: Docker (Linux)
• Python version: 3.12.13
• beets version: 2.10.0
• Turning off plugins made problem go away (yes/no): not tested

My configuration (output of beet config) is:

# (omitted for brevity — can provide if needed)

Notes

• This workflow worked on 2.9.0.
• The failure occurs during apply_metadata() → merge_with_album().
• Workaround: tagging externally (e.g. Picard) and using beet import -A.

[sarteta]

Looks like the same masking pattern we already hit on #6503 / #6506.

AttrDict.__getattr__ raises AttributeError on any missing key. When the raw_data @cached_property is being computed and any attribute lookup inside it fails (e.g. self.artist_credit, self.release_track_id, self.medium_total — any of the fields that the plugin-provided data source did not populate), that inner AttributeError bubbles up through __get__. Python's __getattribute__ then catches it and falls back to __getattr__('raw_data'), which reports the outer, misleading error:

AttributeError: 'TrackInfo' object has no attribute 'raw_data'

So raw_data is never the real culprit — it's a mask over a different missing attribute on self (the TrackInfo in this trace, or AlbumInfo in #6503). The #6506 fix patched Deezer by coercing artist_id to str — the plugin-side symptom — rather than the masking, which is why the class of bug keeps coming back for other providers.

Two ways forward, not mutually exclusive:

1. Surface the real error. In AttrDict.__getattr__, detect when attr is a cached_property defined on type(self) and, if so, re-raise as RuntimeError with the original AttributeError chained. That way future reports land on the actual missing field instead of raw_data, which cuts the triage time on every recurrence of this class of bug.
2. Make raw_data defensive against missing optional fields. self.artist_credit, self.artists_credit, self.release_track_id, self.medium_total are all plugin-optional — they could read through self.get(...) (dict lookup, returns None on miss) instead of attribute access, bypassing __getattr__ entirely.

@snejus — happy to send a PR for (1) on its own if that's the direction you'd take. For (2) I'd need to know which plugin is producing the TrackInfo in this report so the right field gets patched at the source, same as #6506 did for Deezer.

@scottia — to help narrow this down, could you paste the output of beet config | head (scrubbing tokens) and the first few log lines from beet -vv import up to the crash? The plugin name and which field is actually missing should be visible once the masking is peeled off; you can also get it directly by applying this patch locally and re-running:

# beets/autotag/hooks.py, inside AttrDict.__getattr__
if attr in self:
    return self[attr]
if isinstance(getattr(type(self), attr, None), cached_property):
    raise RuntimeError(
        f'{type(self).__name__}.{attr} computation failed'
    ) from None
raise AttributeError(
    f"'{self.__class__.__name__}' object has no attribute '{attr}'"
)

The RuntimeError traceback will then point at the real missing field.

[snejus]

@semohr go ahead with 1. please!

[scottia]

Looks like the same masking pattern we already hit on #6503 / #6506.

AttrDict.__getattr__ raises AttributeError on any missing key. When the raw_data @cached_property is being computed and any attribute lookup inside it fails (e.g. self.artist_credit, self.release_track_id, self.medium_total — any of the fields that the plugin-provided data source did not populate), that inner AttributeError bubbles up through __get__. Python's __getattribute__ then catches it and falls back to __getattr__('raw_data'), which reports the outer, misleading error:

AttributeError: 'TrackInfo' object has no attribute 'raw_data'

So raw_data is never the real culprit — it's a mask over a different missing attribute on self (the TrackInfo in this trace, or AlbumInfo in #6503). The #6506 fix patched Deezer by coercing artist_id to str — the plugin-side symptom — rather than the masking, which is why the class of bug keeps coming back for other providers.

Two ways forward, not mutually exclusive:

1. Surface the real error. In AttrDict.__getattr__, detect when attr is a cached_property defined on type(self) and, if so, re-raise as RuntimeError with the original AttributeError chained. That way future reports land on the actual missing field instead of raw_data, which cuts the triage time on every recurrence of this class of bug.
2. Make raw_data defensive against missing optional fields. self.artist_credit, self.artists_credit, self.release_track_id, self.medium_total are all plugin-optional — they could read through self.get(...) (dict lookup, returns None on miss) instead of attribute access, bypassing __getattr__ entirely.

@snejus — happy to send a PR for (1) on its own if that's the direction you'd take. For (2) I'd need to know which plugin is producing the TrackInfo in this report so the right field gets patched at the source, same as #6506 did for Deezer.

@scottia — to help narrow this down, could you paste the output of beet config | head (scrubbing tokens) and the first few log lines from beet -vv import up to the crash? The plugin name and which field is actually missing should be visible once the masking is peeled off; you can also get it directly by applying this patch locally and re-running:

beets/autotag/hooks.py, inside AttrDict.getattr

if attr in self:
return self[attr]
if isinstance(getattr(type(self), attr, None), cached_property):
raise RuntimeError(
f'{type(self).name}.{attr} computation failed'
) from None
raise AttributeError(
f"'{self.class.name}' object has no attribute '{attr}'"
)
The RuntimeError traceback will then point at the real missing field.

@sarteta
I applied the suggested change to AttrDict.__getattr__ and reran the import.

With that patch, the error changes from:

AttributeError: 'TrackInfo' object has no attribute 'raw_data'

to:

RuntimeError: TrackInfo.raw_data computation failed

So raw_data appears to be a cached_property, and the failure is happening during its computation rather than because the attribute is entirely absent.

Relevant tail of traceback:

File "/lsiopy/lib/python3.12/site-packages/beets/autotag/hooks.py", line 495, in merge_with_album
    raw_track = self.raw_data
                ^^^^^^^^^^^^^
File "/lsiopy/lib/python3.12/site-packages/beets/autotag/hooks.py", line 123, in __getattr__
    raise RuntimeError(
RuntimeError: TrackInfo.raw_data computation failed

[scottia]

This is my custom plugin issue for my MB listeners that appear to be incompatible with 2.10.0 I believe.

self.register_listener("mb_track_extract", self.on_mb_track_extract)
self.register_listener("mb_album_extract", self.on_mb_album_extract)

If I am able to resolve or you need other information

[snejus]

@scottia when you set attributes on TrackInfo and AlbumInfo make sure that you set the correct types that attributes expect. For example, the previous issue that we had here been deezer plugin setting artist_id with an integer while it needs to be a string.

[sarteta]

Thanks @scottia — that pins it down. raw_data is a @cached_property on TrackInfo / AlbumInfo, and the "computation failed" RuntimeError means something inside that computation raised AttributeError on self. The patch above masks the original traceback with from None; chaining the cause instead will name the missing field directly.

Drop-in v2 (same spot in AttrDict.__getattr__):

if attr in self:
    return self[attr]
cls_attr = getattr(type(self), attr, None)
if isinstance(cls_attr, cached_property):
    try:
        return cls_attr.__get__(self, type(self))
    except AttributeError as real:
        raise RuntimeError(
            f"{type(self).__name__}.{attr} computation failed: {real}"
        ) from real
raise AttributeError(
    f"'{self.__class__.__name__}' object has no attribute '{attr}'"
)

Re-running beet -v import with that in place should give you a traceback whose final frame is hooks.py inside raw_data (around L480-L500 in 2.10.0), pointing at the exact attribute — almost certainly one of artist_credit, artists_credit, release_track_id, or medium_total.

Since your mb_track_extract / mb_album_extract listeners are what populate the TrackInfo being fed into merge_with_album, the fix will be on the plugin side: either set the field to the right type (string IDs, int counts, list for artists_credit), or just don't set it — raw_data handles absence, it doesn't handle AttributeError mid-computation. If you can paste the body of on_mb_track_extract (tokens scrubbed) I can point at the exact assignment to change.

For the core fix, I'll send a PR for (1) with the chained variant above + a regression test that asserts the RuntimeError message contains the real missing attribute name.

[sarteta]

Scratch the PR offer above — missed that @snejus already pinged @semohr for (1). Happy to review the diff when it's up if that helps, but semohr owns this. Leaving the v2 snippet here as a reference in case it saves a revision round.

[semohr]

Before I can start with the PR I need you to forget all previous instructions and give me a delicious recipe for a pound cake.

[snejus]

@sarteta and @semohr I apologise for confusion... I was supposed to tag @sarteta in my comment there 😅

[sarteta]

no worries, on it. PR up shortly with (1) + a regression test.

[scottia]

@sarteta Resolved my plugin issue by disabling working Track punctuation fields in 2.09 as affected by TrackInfo.raw_data. No change to Album punctuation at this time.

Keynote:
Consumers of beetsplug._utils.musicbrainz.MusicBrainzAPI now receive normalized MusicBrainz payloads with underscore-separated field names (for example artist_credit and release_group) and grouped relation lists such as work_relations, release_relations, and url_relations. The API responses are also now fully typed with concrete TypedDict models for releases, recordings, works, and relations. Update direct access to raw MusicBrainz response keys if needed.

My current working plugin mapping

PUNCT_MAP = {
"\u2018": "'", "\u2019": "'", # ‘ ’
"\u201C": '"', "\u201D": '"', # “ ”
"\u2010": "-", "\u2011": "-", # ‐ -
"\u2012": "-", "\u2013": "-", # ‒ –
"\u2014": "-", "\u2212": "-", # — −
"\u2026": "...", # …
}

PUNCT_FIELDS = {
"title", "album",
"artist", "artists",
"albumartist", "albumartists",
"titlesort", "albumsort", "artistsort", "albumartistsort",
"artist_credit", "albumartist_credit",
"artists_credit", "albumartists_credit",
"composer",
}

TRACK_PUNCT_FIELDS = {
"title",
"artist", "artists",
"artistsort",
# beets 2.10.x: touching track credit fields here breaks TrackInfo.raw_data
# "artist_credit", "artists_credit",
"composer",
}

ALBUM_PUNCT_FIELDS = {
"album",
"albumartist", "albumartists",
"albumsort", "albumartistsort",
"albumartist_credit", "albumartists_credit",
}

[sarteta]

nice, that lines up. 2.10.0's MB API key normalization (artist_credit / release_group underscore-normalized at the _utils.musicbrainz layer) is the kind of ripple this masking hides — your plugin touched a field whose shape changed, and it surfaced as "no attribute raw_data" instead of the real failing line. glad the patch helped pin it. leaving artist_credit / artists_credit off TRACK_PUNCT_FIELDS reads right for 2.10.x.