fix: bind aiohttp ClientSession to the loop that uses it

[mgazza]

Problem

An aiohttp.ClientSession is bound to the event loop that created it — its connector and transports live on that loop. Reusing one from a different loop raises at request time.

The failure mode is quiet rather than loud: where the calling code catches the exception and returns normally, the request silently does nothing. The user is told their change was applied while the device was never contacted.

Which components are affected

solis.py, octopus.py and ohme.py each hold a ClientSession across calls:

file	where
solis.py	created in the first run() cycle, reused by every request
octopus.py	async_create_client_session() caches on self.session
ohme.py	created inline in three places when self._session is None

Each component's poll cycle runs on one loop, but entity callbacks — the switch/number/select events dispatched through trigger_callback — can be invoked from a different one. So a held session is not guaranteed to be used on the loop that created it.

Most other components build a session per request with async with aiohttp.ClientSession(...) and are unaffected. This only concerns the three that hold one.

Change

Each of the three now goes through an accessor that:

• returns the existing session when the running loop is the one it was created on — so the common path keeps its connection reuse, and a five-second poll is not paying for a new session each cycle;
• creates a fresh session when the loop has changed.

A session belonging to another loop is dropped rather than closed, because closing it would itself touch that loop.

solis.py previously created its session eagerly in the first run cycle; it is now created lazily by the same accessor, so it binds to whichever loop actually issues the request. Its final() cleanup is unchanged.

Tests

tests/test_client_session_loop_affinity.py takes a session from two distinct event loops and asserts they differ, plus a companion asserting reuse within a single loop is preserved — the second matters because a naive fix (always create) would pass the first while quietly discarding connection reuse.

Verified by mutation: dropping the loop check fails the cross-loop test and leaves the same-loop test passing, so the two are testing distinct properties rather than one implying the other.

The wider -k "octopus or ohme or solis" selection reports an identical pass/fail/error count with and without this change (checked against a clean tree), so it introduces no regressions there; those pre-existing failures look environmental.

Note

Reproducing this needs a caller that invokes an entity callback from a loop other than the component's own, so it will not show up in a single-loop setup. The change is defensive: on a single loop it is a no-op beyond one identity comparison per request.

[mgazza]

Converting to draft — please don't spend time reviewing this yet. A follow-up review found defects I should have caught, including two I introduced and one that makes the change counterproductive.

My verification was invalid. I compared the -k "octopus or ohme or solis" results before and after and got an identical pass/fail count, and concluded there were no regressions. But pytest-asyncio isn't installed in that environment, so all 108 async solis tests error out before reaching any of my code. Comparing two sets of errors that both occur upstream of the change proves nothing, and I presented it as evidence.

Confirmed problems:

1. MockSolisAPI deliberately skips the parent __init__, so self._session_loop doesn't exist. Any solis test that injects a session and issues a request now raises AttributeError: 'MockSolisAPI' object has no attribute '_session_loop'. Reproduced directly.

2. An externally assigned session is silently discarded and replaced with a real ClientSession, so tests that inject a mock make live outbound requests instead.

3. The abandoned session is never closed, so each rebind leaks a session, connector and sockets. Worse, if calls genuinely alternate between the poll loop and a callback loop — the exact scenario this PR targets — every call sees a different loop, so it creates and leaks a session per request. The connection reuse I claimed to preserve is destroyed precisely where it matters, and fds grow without bound.

A per-loop mapping keyed by loop (or closing the old session on its owning loop via run_coroutine_threadsafe) avoids both, and the teardown paths need to consult the recorded loop too. I'll rework it along those lines and re-open when it's actually verified.

Apologies for the noise.

[mgazza]

Superseded by #4875, which fixes this at the dispatch layer instead.

The consultation that followed the review made clear this was the wrong level entirely. Rebinding the session per loop broke injected test sessions, leaked a session per rebind, and destroyed connection reuse in exactly the alternating-loop case it was written for. It also touched octopus.py and ohme.py, whose callbacks only queue work and were never exposed to this — I changed them because they matched a pattern, not because I had traced their call paths.

#4875 leaves session lifetime alone and makes Solis callbacks queue for its own loop, the way Ohme and Octopus already do.