teslamate-org / teslamate / 81070657831e87a50b2726bda9b3c694a3e36627

81%

Build Type

push

github

Committed by web-flow

Commit Message

fix(vehicle): back off on Fleet API EXCEEDED_LIMIT responses (#5476)

* fix(vehicle): back off on Fleet API EXCEEDED_LIMIT responses

Tesla's Fleet API returns 403 {"error": "account disabled: EXCEEDED_LIMIT"}
when the app's rate limit is exceeded, but this response wasn't matched by
any specific clause in TeslaApi.Vehicle.handle_response/2, so it fell
through to the generic :unknown handler. That handler retries every
10-30 seconds depending on vehicle state, with no backoff - so once an
app hits this limit, TeslaMate keeps hammering the already-rate-limited
endpoint indefinitely instead of backing off, which can prolong the block.

This routes the EXCEEDED_LIMIT response through the existing
:too_many_request handling (the same path used for HTTP 429 responses),
backing off for 15 minutes instead. Tesla doesn't send a retry-after
header for this error, so 15 minutes is a fixed, conservative default.

* fix(vehicle): handle :too_many_request in list_vehicles! and fetch_strict

Testing the previous commit against a live EXCEEDED_LIMIT ban surfaced
two spots where {:error, :too_many_request, retry_after} was never
handled, even though this shape already existed for plain HTTP 429s:

- Vehicles.list_vehicles!/0 (called once at application boot) had no
  matching case clause, so a rate-limited "list vehicles" call crashed
  the whole application at startup - and with restart: always, that's
  a boot-crash-loop that keeps calling the rate-limited endpoint.
- Vehicle.fetch_strict/2 (used by the manual "suspend logging" action)
  had the same gap, which would crash that vehicle's process if
  triggered while rate-limited.

Both now fall back gracefully instead of crashing: list_vehicles! uses
its existing fallback_vehicles() (cached cars from the DB), and
fetch_strict returns {:error, {:too_many_request, retry_after}} in the
same {:error, reason} shape its one caller already expects.

Coverage Stats

0 of 3 new or added lines in 2 files covered. (0.0%)

1 existing line in 1 file now uncovered.

1956 of 2419 relevant lines covered (80.86%)

2972.53 hits per line