Skip to content

Improve auth token handling for v2 - #137

Open
heyiamluke wants to merge 8 commits into
cdpuk:mainfrom
heyiamluke:main
Open

Improve auth token handling for v2#137
heyiamluke wants to merge 8 commits into
cdpuk:mainfrom
heyiamluke:main

Conversation

@heyiamluke

Copy link
Copy Markdown

Fixes a class of bugs where the integration silently stops working after a few days and requires removing and re-adding the device to recover. Root cause: cloud auth tokens can be invalidated server-side without warning, and the integration had no path to recover. Also widens HTTP timeouts, which were tight enough to cause spurious "Timeout fetching" failures and repeated Unavailable/Connected flapping even on a healthy connection.

Have tested for a number of days and now don't experience any issues

claude and others added 8 commits July 28, 2026 18:05
Cloud tokens for both backends can be invalidated server-side without
warning after a couple of days. Previously this went unnoticed:
AwsIotApi.fetch_data() swallowed every per-device auth exception, the
Gizwits WebSocket kept retrying forever with the same rejected token,
and neither backend ever escalated to Home Assistant's reauth flow -
so users had to remove and re-add the integration to force a fresh
login.

The coordinator now catches auth exceptions from either backend,
transparently re-authenticates using stored credentials, and retries.
Only a genuine credential failure (e.g. password changed) escalates to
ConfigEntryAuthFailed, which now has a real reauth flow to land in via
config_flow.py's new async_step_reauth.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TrGm9fWhBjtoprZ9zoYeKp
The initial authenticate() call during setup only caught
AwsIotAuthException, so a plain network hiccup (e.g. DNS not ready yet
at HA startup) surfaced as an uncaught TimeoutError and hard-failed the
config entry instead of triggering HA's normal retry-with-backoff via
ConfigEntryNotReady. The Gizwits setup path already handled this
correctly; AWS IoT now does too.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TrGm9fWhBjtoprZ9zoYeKp
Reports of repeated "Timeout fetching Bestway API data" and "AWS IoT
setup failed, will retry" over multiple hours (not just at startup)
indicate the 10s budget is too tight for some users' network paths to
Bestway's cloud. The coordinator's outer timeout wrapped both
refresh_bindings() and a per-device fetch loop in the same 10s window
that each individual HTTP call was already using internally, leaving
no slack anywhere in the chain - a single slightly-slow response could
fail the whole update cycle.

Bump per-request timeouts (both backends) from 10s to 20s, and give
the coordinator's update cycle its own 30s budget so it isn't the
first thing to fail when a call is merely slow rather than dead. Also
include the exception type in the AWS IoT setup retry log line, since
TimeoutError's message is empty and the log was showing nothing useful
after the colon.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TrGm9fWhBjtoprZ9zoYeKp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants