Raise ConfigEntryNotReady when Tuya setup hits a network error - #176124
Conversation
Setup errors from update_device_cache propagated as unhandled exceptions, so starting Home Assistant without network connectivity left the Tuya config entry permanently failed until a manual reload. Map requests transport errors to ConfigEntryNotReady so setup is retried automatically and recovers once connectivity returns.
|
Hey there @tuya, @zlinoliver, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
| # Get all devices from Tuya, makes blocking web calls | ||
| try: | ||
| manager.update_device_cache() | ||
| except requests.exceptions.RequestException as exc: |
There was a problem hiding this comment.
I don't think it should handle all RequestException errors.
I suggest to start with just ConnectionError:
| except requests.exceptions.RequestException as exc: | |
| except requests.exceptions.ConnectionError as exc: |
There was a problem hiding this comment.
Done — narrowed to requests.exceptions.ConnectionError. Thanks for the review!
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c521abb7a7
ℹ️ 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".
| # Get all devices from Tuya, makes blocking web calls | ||
| try: | ||
| manager.update_device_cache() | ||
| except requests.exceptions.ConnectionError as exc: |
There was a problem hiding this comment.
Retry Tuya setup after read timeouts
When the Tuya endpoint accepts the connection but stops responding, the SDK's requests call with its timeout raises requests.exceptions.ReadTimeout/Timeout, which is not a subclass of ConnectionError. That still falls through to the broad exception handler and leaves the entry in SETUP_ERROR instead of SETUP_RETRY, so a common transient network failure still requires a manual reload despite this retry handling.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Deliberately scoped: epenet asked above to start with just ConnectionError rather than the broader RequestException family (#176124 (comment)). Note connect-phase timeouts are covered (ConnectTimeout subclasses ConnectionError); read timeouts can be widened in a follow-up if the maintainers want it.
🤖 Addressed by Claude Code
Proposed change
Tuya setup errors from
manager.update_device_cache()propagated as unhandled exceptions: only thesign invalidcase was mapped (toConfigEntryAuthFailed), so starting Home Assistant while the network/DNS was down left the Tuya config entry permanently failed until a manual reload or restart (see the reproduction steps in the issue).This maps
requeststransport errors toConfigEntryNotReady, so Home Assistant retries setup automatically and the integration recovers on its own once connectivity returns. Thesign invalidreauth path is unchanged (the new branch only catchesrequests.exceptions.RequestExceptionand runs first).Regression test: a
ConnectionErrorfromupdate_device_cacheputs the entry inSETUP_RETRY; it fails on the unpatched code (unhandled exception → permanentSETUP_ERROR).Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.