tidal: respect search_limit config option in candidates()

[kveni12]

Fixes #6770

Problem

TidalPlugin extends MetadataSourcePlugin, which sets a default search_limit: 5 config value. However, candidates() and item_candidates() called search_albums_by_query() and search_tracks_by_query() without any limit, so the config option was silently ignored.

Fix

• Add an optional limit: int | None = None parameter to search_albums_by_query() — slices album_ids before passing to search_albums_by_ids()
• Add an optional limit: int | None = None parameter to search_tracks_by_query() — slices the track relationships list before iterating
• candidates() reads self.config["search_limit"].get(int) and passes it through
• item_candidates() does the same

The fix is intentionally minimal — no changes to api.py or the Tidal HTTP request; results are simply sliced client-side, consistent with how other direct-implementation plugins cap their results.

Tests

Added TestSearchLimit with two tests:

• test_candidates_respects_search_limit — sets search_limit: 1, mocks search_results returning 2 album IDs, asserts only 1 candidate is returned
• test_item_candidates_respects_search_limit — same pattern for tracks

[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.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.85%. Comparing base (bf879d5) to head (c33a520).
⚠️ Report is 7 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #6781   +/-   ##
=======================================
  Coverage   74.84%   74.85%           
=======================================
  Files         163      163           
  Lines       20949    20946    -3     
  Branches     3300     3297    -3     
=======================================
- Hits        15680    15679    -1     
+ Misses       4511     4510    -1     
+ Partials      758      757    -1     

Files with missing lines	Coverage Δ
beetsplug/tidal/__init__.py	89.33% <100.00%> (-0.05%)	⬇️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[semohr]

Thanks for already taking a look here!

We should be able to resolve all search limit based logic within the candidates and item_candidates function. I don't really see the need for the extensive drilling.

The search_tracks_by_query and search_albums_by_query functions are returning iterators. We should be able to break them early and limit the number of requests that way.

Additionally the search_limit currently does not respect the _album_queries and _item_queries loop. We might want to have a round robin approach here.

---

I will have a more detailed look next week.

[snejus]

I've added it to my fork using a slightly simpler solution 626963d

[kveni12]

hi @semohr thank you for the feedback! I completely agree, so moved the limit logic entirely into candidates() and item_candidates() using a round-robin loop that early-breaks across query iterators, so search_albums_by_query and search_tracks_by_query stay clean. Also added a test covering the multi-query interleaving behaviour.

[semohr]

Lets make the round robin logic a helper function. Should make the flow here more readable and should allow to dedupe some code.

[snejus]

What is zip_longest here for? Also, you can use filter(None, ... instead of checking for None values.