spotify: Handle API failures

[9999years]

Lots of these weren't handled, leading to crashes while importing.

To Do

• Documentation. (If you've added a new command-line flag, for example, find the appropriate page under docs/ to describe it.)
• Changelog. (Add an entry to docs/changelog.rst to the bottom of one of the lists near the top of the document.)
• Tests. (Very much encouraged but not strictly required.)

[github-actions]

Thank you for the PR! The changelog has not been updated, so here is a friendly reminder to check if you need to add an entry.

[Copilot]

Pull Request Overview

This PR improves error handling in the Spotify plugin by adding proper exception handling around API calls that previously could crash during imports. The changes wrap critical Spotify API interactions with try-catch blocks to gracefully handle API failures.

Key changes:

• Added exception handling for API failures in album and track retrieval methods
• Modified track_info method to return None on API errors instead of crashing
• Updated type annotations to reflect the new nullable return types

[Copilot]

[nitpick] The return type annotation is verbose and unclear. Consider creating a type alias or using a more descriptive approach, such as TrackInfoTuple | None where TrackInfoTuple = Tuple[Optional[Any], Optional[Any], Optional[Any], Optional[Any]].

Suggested change

	) -> Tuple[Any | None, Any | None, Any | None, Any | None] | None:
	) -> TrackInfoTuple | None:

[codecov]

Codecov Report

❌ Patch coverage is 18.51852% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.67%. Comparing base (5beb3d1) to head (55b3e45).

Files with missing lines	Patch %	Lines
beetsplug/spotify.py	18.51%	21 Missing and 1 partial ⚠️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[snejus]

This approach introduces a lot of duplication in the code. I think a cleaner approach would be to never raise APIError in the first place.

See _handle_response method - I'd suggest removing all lines that raise APIError and returning None instead.

[semohr]

Maybe it is worth taking a step back here:

How do we want to handle errors in metadata plugins in general? E.g. what should happen if one plugin fails because a remote service is currently unreachable? Do we want beets to crash here or just warn a user?

I think raising errors in the specific metadata plugin (such as spotify or deezer) is completely fine. We should handle errors globally for any metadata plugins tho and warn users.

Proposal: Let's add error handling to the metadata_plugins.py file and warn the user that some plugin(s) did not complete a lookup or function call successfully. This would also move responsibilities away from the plugin developers and reduce unnecessary & duplicate error handling.