perf: fast-fail HACS not-found lookups + batch-verify deep-search E2E fixtures (#1515)

[kingpanther13]

What does this PR do?

Removes the largest fixed waits from the HAOS E2E suite — the floor that
dominates cache-hit runs (#1515) — without dropping any coverage. Measured on
the external HAOS lane: ~414s → ~350s (≈60s, ~15% faster), consistent
across runs (the run-to-run spread is QEMU-boot jitter). The HACS and deep-search
waits below were in the suite's slowest-10 and are gone from it after the change;
the scene/climate/bulk-light waits were ~10s tail entries, also trimmed — no
coverage dropped.

1. perf(hacs): fast-fail not-found repo lookups (~60s of suite time).
_resolve_hacs_repo_id — the owner/repo lookup behind read-only
ha_get_hacs_info(action="info") and ha_manage_hacs(action="download") —
waited the full 30s HACS_REPO_REGISTRATION_TIMEOUT whenever the repo was
absent. That budget exists for ha_install_mcp_tools, which adds a repo and
genuinely waits for the fresh registration. A plain info/download lookup
targets a repo that should already be in HACS's index (default repos always
are; add_repository blocks until registered), so the post-subscribe sample
resolves an existing repo instantly and the dispatch-signal wait only burns
wall-clock on a genuinely-missing repo. New dedicated
HACS_RESOLVE_REGISTRATION_TIMEOUT = 10.0: still event-driven (instant on the
rare mid-registration race), fails a not-found lookup ~3x faster. User-facing:
HACS errors on a missing repo return in ~10s instead of stalling 30s.

2. test(e2e): batch-verify bulk registrations with a post-subscribe sample (~66s).
wait_for_entities_registered_via_ws only waited for state_changed events
with no post-subscribe sample — the one event-driven waiter in
wait_helpers.py missing it. An entity that registered before the subscribe
landed never re-fires an observable event, so the wait burned the entire 30s
budget then fell back to REST. The deep-search bulk fixtures hit this every
run (the fixed ~30s was identical for 10 automations and 5 scripts — the tell
that it's a timeout, not per-entity cost). Adds a single get_states sample
over the same WS right after subscribe (mirrors the pattern the other waiters
use), and switches the fixtures to wait=False creates so registration is
batch-verified in one WS wait instead of N sequential per-create polls.

3. fix(service): don't run a doomed state-change wait on scene.turn_on (~10s).
ha_call_service waited for the scene entity to reach state "on", but a
scene's own state is a last-activated timestamp that never becomes "on"/"off",
so the wait always ran out its 10s timeout and appended a spurious "could not
be verified" warning. Adds scene to _NON_STATE_CHANGING_DOMAINS alongside
automation/script (activating a scene changes member entities, not the
scene entity's state). Real callers get a snappy scene.turn_on too.

4. test(e2e): trim two more doomed device-control waits + repair a broken fallback.

• test_climate_control: wait=False on set_temperature/set_hvac_mode
  (the test asserts only on attributes; set_temperature moves an attribute,
  not the primary state the verifier waits for). ~10s.
• test_bulk_light_control: informational operation-status poll 10s → 3s
  (status is asserted nowhere; WS-resolvable ops finish sub-second). ~7s.
• The deep-search bulk fixtures' REST fallback polled a non-existent
  ha_list_states tool — harmless dead code while creates used the per-call
  registration wait, but load-bearing once they use wait=False. Replaced with
  a per-entity ha_get_state poll that now fails loudly if registration never
  lands (instead of silently yielding unregistered entities).

5. ci: prime the shared HAOS image cache from master (image-acquisition, a separate axis).
Investigation (the addon is injected at runtime — inaddon via offline overlay + Supervisor update, external via in-process import — so the cache key correctly excludes src/ha_mcp/homeassistant-addon-dev) showed the cache key is already optimally scoped; there's no key-trimming win to take. The real issue: the multi-GB qcow2 is a large fraction of GitHub's 10 GB Actions-cache cap and nothing primes it except a PR's branch-scoped lazy save, so new PR branches start cold and pay the GHCR pull (usually ~50s, occasionally 600s+). The master/cron image-publish job now also actions/cache/saves the qcow2 under the lanes' exact key, so PRs restore one durable default-branch entry instead of pulling GHCR (and a cache hit skips the per-PR save, stopping the cap thrash). Purely additive (GHCR fallback unchanged on miss/eviction), best-effort (never fails the publish job). Both lanes emit a ::notice:: with the cache-hit status. This lands on PRs cut after merge (master populates it), so it doesn't speed up this PR's own runs.

Unit tests pin the new behavior: HACS resolve-budget wiring + a numeric bound
(< HACS_REPO_REGISTRATION_TIMEOUT), and scene.turn_on not waiting.

The slowest-10 after this PR is entirely irreducible QEMU boot or genuinely-slow
work (real backups, the deliberate code-mode timeout test, addon WS-proxy
validation) — each was investigated and left alone rather than masked.

Type of change

• 🐛 Bug fix
• ✨ New feature
• 📚 Documentation
• 🔧 Maintenance/refactor
• 🧪 Tests only
• 💥 Breaking change

Testing

• I have tested these changes with a LLM agent
• All automated tests pass (uv run pytest)
• Code follows style guidelines (uv run ruff check)

Verified across CI runs: both HAOS E2E lanes (external + inaddon), testcontainer
E2E (E2E Validation), Unit Tests, Mypy, and Ruff. The CI cache-prime (item 5)
touches only the master-triggered image-publish job — not exercised by PR CI —
plus a trivial cache-status notice step in each lane. Local Docker is unavailable
in this environment, so the HAOS suite is the verification venue; the LLM-agent
box is N/A for E2E-infra changes.

Checklist

• I have updated documentation if needed

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on optimizing the Home Assistant OS E2E test suite by addressing two major performance bottlenecks. By refining the HACS repository resolution timeout and improving the WebSocket registration wait logic, the changes eliminate unnecessary idle time during test execution. These improvements significantly reduce the overall suite duration without sacrificing test coverage or reliability.

Highlights

• HACS Performance Optimization: Introduced a faster 10-second timeout for HACS repository lookups, significantly reducing the wait time for non-existent repositories from 30 seconds.
• E2E Test Suite Acceleration: Optimized the bulk registration wait helper by adding a post-subscribe state sample, preventing unnecessary timeouts when entities are already registered.
• Bulk Fixture Refactoring: Updated bulk automation and script fixtures to use batch-verified registrations, removing redundant sequential polling and saving over a minute of total suite execution time.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request optimizes registration wait times and timeouts to prevent unnecessary stalls in the E2E test suite and HACS lookups. It introduces a shorter HACS_RESOLVE_REGISTRATION_TIMEOUT (10s) for HACS repository resolution, updates bulk automation and script creation tests to use wait=False to batch-verify registrations, and enhances wait_for_entities_registered_via_ws with a post-subscribe get_states sample to immediately catch already-registered entities. A unit test was also added to verify the fast-fail timeout behavior. I have no feedback to provide as there are no review comments.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[github-actions]

🧪 Your changes are now in the dev channel!

Your PR has been merged to master and is available for testing in the dev channel.

Test your changes before the next stable release (biweekly Wednesday):
📖 Dev Channel Documentation

Quick start

# Run dev version
uvx ha-mcp-dev

# Check version
uvx ha-mcp-dev --version

Docker:

docker pull ghcr.io/homeassistant-ai/ha-mcp:dev
docker run --rm -i \
  -e HOMEASSISTANT_URL=http://your-ha:8123 \
  -e HOMEASSISTANT_TOKEN=your_token \
  ghcr.io/homeassistant-ai/ha-mcp:dev

---

Found an issue? Please open a new bug report and mention this PR for context.