fix(tesla): retry site_info after transient network failures

[Artic0din]

Problem

A transient Tesla/PowerSync API failure permanently disables site_info fetches until the integration reloads or Home Assistant restarts.

Evidence

At 03:08:15, four concurrent site_info calls exhausted their retries during a wider DNS/network outage. Each logged:

Failed to fetch site_info: ... (will not retry until next restart)

No further fetch occurred after network recovery. Fetching resumed only after the config entry reloaded at 06:03:57.

The live 2.12.857 coordinator sets _site_info_fetch_failed = True; every later call immediately returns None.

Root cause

The negative cache does not distinguish permanent configuration/authentication failures from transient DNS, connection, or timeout failures. It has no expiry or recovery probe.

Proposed fix

• Classify authentication/configuration failures separately from transient transport failures.
• Replace the permanent boolean negative cache for transient failures with timestamped exponential backoff.
• Preserve and return the last valid cached payload while a retry is deferred.
• Log one failure transition and one recovery transition rather than every caller.
• Retain explicit re-authentication behavior for genuine credential failures.

Acceptance criteria

• A DNS or connection failure retries automatically after backoff without reload/restart.
• A successful retry clears the failure state and logs recovery once.
• Cached valid site_info remains available during a transient outage.
• Authentication failures do not create an aggressive retry loop.
• Tests cover timeout, DNS failure, auth failure, cached fallback, and recovery.

---

Migration source: PLA-154
Linear status at cutover: Backlog
Cut over to GitHub on 2026-07-22.

[Artic0din]

Related amplification issue\n\nThe permanent negative-cache failure was triggered four times concurrently because async_get_site_info() does not coalesce in-flight requests. That independent request-stampede defect is tracked as sub-issue #31.

[github-actions]

🤖 This is an automated response from Repo Assist.

Root Cause Analysis

The permanent-failure flag lives in coordinator.py at lines 2320 and 2435–2440. Once _site_info_fetch_failed = True is set, line 2079 skips all future fetches — even after network recovery.

Suggested Fix

Replace the permanent flag with a retry-after window (e.g. 30 minutes):

# Replace: self._site_info_fetch_failed = False
self._site_info_next_retry: float = 0  # monotonic time

# Replace check at line 2079:
if _site_info_stale and time.monotonic() >= self._site_info_next_retry:
    ...

# On failure (lines 2435-2440):
self._site_info_next_retry = time.monotonic() + 1800  # retry in 30 min

This preserves the log-spam protection while allowing automatic recovery after transient DNS/network outages — matching the observed behaviour where the integration only recovered after a full config-entry reload. The _site_info_fetch_failed attribute can be removed entirely once the retry window is in place.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

🤖 This is an automated response from Repo Assist. Generated by 🌈 Repo Assist; see workflow run. Learn more.
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@1c6668b751c51af8571f01204ceffb19362e0f66