SaicApiClient creates and owns an httpx.AsyncClient, but neither it nor AbstractSaicApi exposes a way to close it. A consumer that constructs a SaicApi, experiences a failed login (or simply finishes using the client), and then tries to clean up has no supported way to release the transport — so the underlying HTTP client stays open until garbage collection or process exit. Under repeated failed logins this leaks connections.
Would you accept a small, additive PR adding async def close() to both SaicApiClient (closing its httpx.AsyncClient via aclose()) and AbstractSaicApi (delegating to the client)? It's backward-compatible — nothing existing changes. Happy to open it. Context: this came up in the mg-saic-ha Home Assistant integration, which currently has to reach the private client to close it.
SaicApiClientcreates and owns anhttpx.AsyncClient, but neither it norAbstractSaicApiexposes a way to close it. A consumer that constructs aSaicApi, experiences a failed login (or simply finishes using the client), and then tries to clean up has no supported way to release the transport — so the underlying HTTP client stays open until garbage collection or process exit. Under repeated failed logins this leaks connections.Would you accept a small, additive PR adding
async def close()to bothSaicApiClient(closing itshttpx.AsyncClientviaaclose()) andAbstractSaicApi(delegating to the client)? It's backward-compatible — nothing existing changes. Happy to open it. Context: this came up in themg-saic-haHome Assistant integration, which currently has to reach the private client to close it.