Fix coordinator stalling by adding HTTP request timeouts - #39
Open
timstoop wants to merge 2 commits into
Open
Conversation
The ducopy library doesn't support timeout parameters on HTTP requests, causing the coordinator to hang indefinitely when the DucoBox device doesn't respond. This results in entities stopping updates for hours until the integration is manually reloaded. This fix adds a custom TimeoutHTTPAdapter that sets a default timeout of (SCAN_INTERVAL - 5s) to all HTTP requests, ensuring: - Requests timeout before the next update cycle begins - Failed requests are properly caught and logged as UpdateFailed - Entities go unavailable on timeout instead of silently stalling - Next update cycle can retry after a failed request Timeout is dynamically calculated based on SCAN_INTERVAL configuration for maintainability. Fixes coordinator stalls observed in production where sensors would stop updating for 6+ hours when the device became unresponsive.
Fixes 7+ hour hangs by implementing dual timeout defense: - Primary: asyncio.wait_for() wrapper (110s timeout) on all executor jobs - Secondary: TimeoutSSLAdapter (55s HTTP timeout) preserving SSL handling - Write operations: 30s timeout for node value/state changes Key changes: - Replace TimeoutHTTPAdapter with TimeoutSSLAdapter to preserve ducopy's SSL context - Wrap all async_add_executor_job calls with asyncio.wait_for() - Add comprehensive logging: endpoint timing, errors with stack traces - Add timeout constants to const.py for maintainability This covers DNS, TCP, SSL handshake, and HTTP timeouts that were previously bypassing the adapter-only approach. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
|
Nice fix! I run into this issue a lot, so hopefully this can be merged soon. |
|
Sikerdebaard/ducopy#18 adds a 15s timeout in the underlying library, which is likely more robust |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The ducopy library doesn't support timeout parameters on HTTP requests, causing the coordinator to hang indefinitely when the DucoBox device doesn't respond. This results in entities stopping updates for hours until the integration is manually reloaded.
Observed Behavior
When the DucoBox device becomes unresponsive (network issues, device busy, etc.), the coordinator silently stalls:
Root Cause
The ducopy library's
DucoUrlSessionextendsrequests.Sessionbut doesn't set timeouts on HTTP calls. Whensuper().request()is called without a timeout parameter, requests can hang indefinitely.Solution
This PR adds a custom
TimeoutHTTPAdapterthat sets a default timeout of(SCAN_INTERVAL - 5 seconds)to all HTTP requests:SCAN_INTERVALfor maintainabilityChanges
TimeoutHTTPAdapterclass that extendsHTTPAdapterwith default timeoutDucoboxCoordinator.__init__to mount the timeout adapter on both http:// and https://