Skip to content

Fix slow Home Assistant logins when a provider fails to finish loading - #5455

Merged
MarvinSchenkel merged 4 commits into
devfrom
claude/github-issue-6003-o8zuss
Aug 8, 2026
Merged

Fix slow Home Assistant logins when a provider fails to finish loading#5455
MarvinSchenkel merged 4 commits into
devfrom
claude/github-issue-6003-o8zuss

Conversation

@OzGav

@OzGav OzGav commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

What does this implement/fix?

A provider whose loaded_in_mass() raised stayed registered and available but never got its ready event set, so every caller waiting for it paid the full timeout - forever. Home Assistant ingress logins wait on it twice per connection, which is the reported 10+ seconds per page load.

The Home Assistant provider walked into this whenever its player control settings held a value that is not an entity ID (a leftover from an earlier config): Home Assistant refuses the whole state subscription over one bad entity ID, so registering the controls failed and took the ready. signal down with it.

  • signal a provider as initialized/ready even when a post load step failed, since it stays registered and available either way
  • drop values that are not entity IDs from the Home Assistant player control settings, logging which one was ignored

Related issue (if applicable):

Types of changes

  • Bugfix (non-breaking change which fixes an issue) — bugfix
  • New feature (non-breaking change which adds functionality) — new-feature
  • Enhancement to an existing feature — enhancement
  • New music/player/metadata/plugin provider — new-provider
  • Breaking change (fix or feature that would cause existing functionality to not work as expected) — breaking-change
  • Refactor (no behaviour change) — refactor
  • Documentation only — documentation
  • Maintenance / chore — maintenance
  • CI / workflow change — ci
  • Dependencies bump — dependencies

Checklist

  • The code change is tested and works locally.
  • pre-commit run --all-files passes.
  • pytest passes, and tests have been added/updated under tests/ where applicable.
  • For changes to shared models, the companion PR in music-assistant/models is linked.
  • For changes affecting the UI, the companion PR in music-assistant/frontend is linked.
  • I have read and complied with the project's AI Policy for any AI-assisted contributions.
  • I have raised a PR against the documentation repository targeting the main or beta branch as appropriate.

@music-assistant music-assistant deleted a comment from musicassistant-bot Bot Aug 7, 2026
@github-actions github-actions Bot added the bugfix label Aug 7, 2026
@musicassistant-bot

musicassistant-bot Bot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

✅ The title and description are good to go. Thanks!

A provider whose loaded_in_mass() raised stayed registered and available
but never got its ready event set, so every caller waiting for it paid
the full timeout - forever. Home Assistant ingress logins wait on it
twice per connection, which is the reported 10+ seconds per page load.

The Home Assistant provider walked into this whenever its player control
settings held a value that is not an entity ID (a leftover from an
earlier config): Home Assistant refuses the whole state subscription over
one bad entity ID, so registering the controls failed and took the ready
signal down with it.

- signal a provider as initialized/ready even when a post load step
  failed, since it stays registered and available either way
- drop values that are not entity IDs from the Home Assistant player
  control settings, logging which one was ignored

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0175XDPLyskM4cJN5j41sgtS
@OzGav
OzGav force-pushed the claude/github-issue-6003-o8zuss branch from f1c7611 to de5d698 Compare August 7, 2026 15:08
Comment thread music_assistant/mass.py Outdated
@OzGav
OzGav force-pushed the claude/github-issue-6003-o8zuss branch from de5d698 to 475c9b4 Compare August 8, 2026 09:51
Signalling the provider as ready from a finally block re-raised right
after, so the steps behind it never ran: no discovery pass (which is
where player providers discover their players) and no default name
persisted. The failure also surfaced only as the generic task warning,
which names the coroutine rather than the provider.

Report the failure against the provider it belongs to and carry on with
the remaining steps instead. A cancellation still propagates, so a
teardown mid load leaves the provider unannounced.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0175XDPLyskM4cJN5j41sgtS
@OzGav
OzGav force-pushed the claude/github-issue-6003-o8zuss branch from 475c9b4 to 361b639 Compare August 8, 2026 09:59
@MarvinSchenkel MarvinSchenkel changed the title Release the waiters of a provider whose post load step failed Fix slow Home Assistant logins when a provider fails to finish loading Aug 8, 2026

@MarvinSchenkel MarvinSchenkel left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice find, thanks @OzGav

@MarvinSchenkel
MarvinSchenkel enabled auto-merge (squash) August 8, 2026 10:45
@MarvinSchenkel
MarvinSchenkel merged commit 07d4f54 into dev Aug 8, 2026
17 checks passed
@MarvinSchenkel
MarvinSchenkel deleted the claude/github-issue-6003-o8zuss branch August 8, 2026 11:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants