Bad interaction: fromfilename and edit plugins

[Vrihub]

Problem

When using both the fromfilename and edit plugin, aborted/canceled edit operations fail to restore the temporary tag data provided by the fromfilename plugin.

Steps to reproduce

1. Import some files lacking metadata tags, but containing useful information in the file name
2. The fromfilename plugin will create tags for track number, artist, title which will be used by the autotagger, e.g. for a search on musicbrainz
3. Select an album release candidate from the musicbrainz search results. In the "match preview" list, on the lefthand side you can see the files identified by the tags generated by the fromfilename plugin (and on the right side the suggested matches from the candidate release).
4. Choose "edit Candidates" and quit your text editor without making any changes
5. Select another candidate (even the same selected in step 3.): now on the lefthand side your files will be identified by the filename, no more info about the track number and titles: those tags generated by the fromfilename plugin are lost.

Notes

• The same happens if you choose "eDit" in step 4. The resulting text file will be correctly populated with tags from the fromfilename plugin, but if you quit the editor and go to step 5. above, the same bug occurs.
• The same happens if, instead of quitting the editor without changes, you actually make some changes, save the file, and select "Cancel" in the next menu.
• Other actions from the import menu don't cause the bug, i.e. I can do multiple searches on musicbrainz by artist/album or release id, and the fromfilename tags are always preserved
• If I don't use the fromfilename plugin and try to import files that already contain some tags, the bug doesn't happen. Tags coming from the file metadata are correctly remembered across aborted edit sessions, only tags coming from the fromfilename plugin are lost.
• "Mixed tags case": if I try to import files that contain tags for artist and track number, but non for title: the fromfilename plugin will generate title tags (equal to the track number, that's expected behaviour), and in step 5. the artist and track tags (coming from the file metadata) will be remembered, while the title tag generated by the fromfilename plugin will be lost.

Hints?

I haven't studied the edit plugin yet, but looking at the history, the bug might be related to 9898451 and/or surrounding commits dealing with correctly restoring objects in multiple edit sessions? Maybe the restoring logic should be fixed also in our "Cancel" case?

Or maybe the bug might be in the fromfilename plugin: should it create the temporary tags in a more "robust" way? I don't know much about beets internals to assess this. I can only observe the tags correctly survive to multiple musicbrainz searches (see third note above), they are only lost after aborted edit sessions.

By the way: the edit plugin documentation https://beets.readthedocs.io/en/stable/plugins/edit.html states:

Also, please be aware that the edit Candidates choice can only be used with the
matches found during the initial search (and currently not supporting the candidates
found via the Enter search or enter Id choices).

it seems this is not true anymore, I can do multiple searches and edit the candidates resulting from each search correctly, so I guess we should update the docs.

Setup

• OS: Linux
• Python version: 3.13.5
• beets version: 2.5.1