Skip to content

Align dependency metadata across manifests - #183

Merged
jleinenbach merged 4 commits into
Bugfixes-for-1.6-beta3from
codex/review-and-update-dependencies-in-project-files
Oct 23, 2025
Merged

jleinenbach merged 4 commits into
Bugfixes-for-1.6-beta3from
codex/review-and-update-dependencies-in-project-files

Conversation

@jleinenbach

Copy link
Copy Markdown
Owner

Summary

  • audit the integration to confirm the runtime third-party packages in use (e.g. httpx[http2], h2, cryptography)
  • synchronize manifest.json, pyproject.toml, and custom requirements.txt to the same dependency set while removing unused entries

Testing

  • ruff format --check
  • pytest -q

https://chatgpt.com/codex/tasks/task_e_68fa3fd2edd08329b0ae939510ad7909

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines 5 to +12
beautifulsoup4>=4.12.3
pyscrypt>=1.6.2
cryptography>=43.0.3
pycryptodomex>=3.21.0
ecdsa>=0.19.0
pytz>=2024.2
protobuf>=6.32.0
frida>=16.5.6
httpx>=0.28.0
ecdsa>=0.19.1
gpsoauth>=2.0.0
h2>=4.1.0
setuptools>=75.6.0
aiohttp>=3.11.8
http_ece>=1.1.0
http-ece>=1.2.1
httpx[http2]>=0.28.0
protobuf>=6.32.0
pycryptodomex>=3.23.0
pyscrypt>=1.6.2
selenium>=4.37.0
undetected-chromedriver>=3.5.5

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Retain aiohttp in development requirements

The update drops aiohttp from the integration’s requirements list, but both runtime code and tests import it directly (e.g., NovaApi/nova_request.py, tests/test_api_location_selection.py). Because requirements-dev.txt pulls from this file via -r custom_components/googlefindmy/requirements.txt, a fresh pip install -r requirements-dev.txt no longer installs aiohttp, resulting in ModuleNotFoundError: No module named 'aiohttp' before pytest can run. Unless another dependency reintroduces aiohttp, the removal breaks the documented dev workflow; consider keeping aiohttp>=3.x or adding it to a dev extra so tests can execute on a clean checkout.

Useful? React with 👍 / 👎.

@jleinenbach
jleinenbach merged commit 9913203 into Bugfixes-for-1.6-beta3 Oct 23, 2025
3 checks passed
@jleinenbach
jleinenbach deleted the codex/review-and-update-dependencies-in-project-files branch October 23, 2025 15:11
jleinenbach added a commit that referenced this pull request Jun 19, 2026
) (#1120)

Issue #183: changing settings (which reloads the config entry) left the
FCM connection status stuck on "Disconnected" until a full Home Assistant
restart. The submitted diagnostics were self-contradictory: the receiver
snapshot was healthy/STARTED while coordinator.fcm_status was degraded
("Push transport not ready; continuing with cached data").

Root cause (empirically reproduced, hypothesis H2): two receiver stores
diverge across a refcount->0 release. _pop_fcm_receiver empties the
per-entry dict fcm_receivers (read by is_push_ready via the provider
getter), but _sync_legacy_fcm_receiver_alias only dropped the legacy
fcm_receiver singleton (read by diagnostics) when it held the wrong type.
A healthy, right-type receiver therefore survived as the singleton while
the per-entry store was empty: is_push_ready() resolved nothing and
returned False (rendered "Disconnected"), while diagnostics still reported
the receiver as healthy/connected.

Fix: treat fcm_receivers as the single source of truth whenever it exists.
When the per-entry dict holds no valid receiver (e.g. after the release
path empties it on reload), drop the legacy alias as well. The legacy
migration path (dict absent entirely, used by _get_fcm_receivers) is
preserved unchanged. This also makes the reload re-acquire reliably
repopulate the store: with no stale singleton to reuse, _async_acquire_
shared_fcm falls through to creating a fresh receiver that re-registers
the per-entry store and providers, so is_push_ready recovers without a
restart.

Tests:
- test_issue_183_reload_fcm_desync.py: alias cleared when dict empties,
  readiness and diagnostics stay consistent, runtime re-sync heals, and
  the absent-dict migration path is preserved.
- test_fcm_receiver.test_reload_reacquire_repopulates_receiver_store:
  full acquire -> release@0 -> re-acquire cycle on the real paths.
- test_coordinator_status: status stays non-CONNECTED while readiness is
  false and recovers on the next cycle once it is true.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
jleinenbach added a commit that referenced this pull request Jul 2, 2026
fix(fcm): recover connection status after settings reload (#183)
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.

1 participant