Bluetooth-Devices/habluetooth

habluetooth

Performance History

Latest Results

fix(build): take C types from the .pxd files, not the .py annotations A source build with a current Cython fails outright: src/habluetooth/auto_scheduler.py:328:4: Signature not compatible with previous declaration src/habluetooth/auto_scheduler.pxd:48:28: Previous declaration is here Cython 3.3 reconciles a .pxd declaration against the annotations on the .py definition, and rejects a bare container type in the .pxd against a parameterised one in the .py: .pxd cpdef void _attach_owned(self, str address, dict entries) .py def _attach_owned( self, address: str, entries: dict[ActiveScanRequest, float] ) -> None Ten declarations hit this, across auto_scheduler.pxd (7) and base_scanner.pxd (3). The build-system requirement is only `Cython>=3`, so this is not a hypothetical: every source build resolves to 3.3 and stops. Only the published wheels still work. Writing the parameterised form into the .pxd does not help -- Cython does not accept `dict[ActiveScanRequest, float]` as a C parameter type there. The types Cython should use are the ones already spelled out in the .pxd files; the annotations exist for mypy and for people reading the code. Say so with `annotation_typing: False`. Trade-off worth stating: functions that are *not* declared in a .pxd no longer get C types inferred from their annotations. Everything on the hot paths here is declared in a .pxd, so this costs nothing that was not already explicit. Verified with Cython 3.3.0: all seven extension modules compile, the wheel carries all seven .so, and the suite passes against the compiled build (899 passed, 1 skipped). Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

rpodgorny:fix/pxd-signatures-match-annotations

2 hours ago

test: cover the disconnect-on-unregister error and no-scanner paths codecov flagged three uncovered spots in the new teardown code. Two are now tested; the third guard is gone. - A client whose disconnect() raises must not break scanner teardown, and the error path must not raise either: it logged client.address, which resolves through the backend that has just failed, so reading it could throw inside the error handler. Log the source and exc_info instead. - Untracking one client must leave the source's other clients tracked. - async_register_client/async_unregister_client now take the scanner rather than a source string. Unregister accepts None, so a client that never finished connecting -- and so never recorded a scanner -- is passed straight through instead of the wrapper testing for it. That moves an unreachable branch out of wrappers.py, where it could not be covered honestly, into the manager, where it is one line to test. - Drop the "loop is None" early return in favour of the TYPE_CHECKING assert this module already uses for _loop elsewhere. manager.py is now at 100% line and branch coverage; the one partial branch left in wrappers.py is pre-existing on main. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

rpodgorny:fix/disconnect-clients-on-scanner-unregister

2 days ago

fix: disconnect clients when their scanner is unregistered Unregistering a scanner tore down every piece of bookkeeping about it -- advertisement tracking, smoothed RSSI, allocations, slot manager entry -- but never touched the connections that had been made through it. For a local adapter those connections are BlueZ D-Bus links. BlueZ has no idea Home Assistant considers the adapter gone, the kernel keeps the link up, and the integration holding the client is never told anything. The device therefore keeps working through an adapter the user has removed, and the allocation bookkeeping that was just cleared has forgotten a connection that still occupies a real slot on the controller. When the adapter is re-registered it starts again at free == slots while that link is still up, so the slot budget can be overcommitted. Track connected clients per source and disconnect them when the scanner goes away. The set is weak, so a client dropped without an explicit disconnect cannot leak, and a client that has already disconnected unregisters itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

rpodgorny:fix/disconnect-clients-on-scanner-unregister

2 days ago

6.26.7 Automatically generated by python-semantic-release

main

5 days ago

fix: notify allocation callbacks when a scanner is unregistered (#607)

main

5 days ago

docs: note that the registration seed is pull only

allocation-callbacks-on-unregister

5 days ago

fix(scanner): check this adapter's passive scan capability on fallback The 4th-start-attempt fallback gated on supports_passive_scan, which is an any() across every adapter on the host. On a mixed-capability host the incapable adapter still took the impossible fallback and hit the same adapter-loss bug the original gate was meant to fix. Add BluetoothManager.supports_passive_scan_for(adapter) and gate the fallback on the scanner's own adapter. The regression test uses the mixed hci0/hci1 shape and fails against the old gate. Both passive fallback tests now patch the manager's adapter cache instead of assigning it, so they no longer leak into the module-scoped manager. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

rpodgorny:fix/passive-fallback-requires-passive-support

5 days ago

docs: document the slots zero sentinel in allocation snapshots

allocation-callbacks-on-unregister

5 days ago

Latest Branches

+13%

fix(build): take C types from the .pxd files, not the .py annotations#610

2 hours ago

e06c219

rpodgorny:fix/pxd-signatures-match-annotations

+3%

fix: disconnect clients when their scanner is unregistered#609

2 days ago

7b234cc

rpodgorny:fix/disconnect-clients-on-scanner-unregister

+2%

fix: notify allocation callbacks when a scanner is unregistered#607

5 days ago

35e5040

allocation-callbacks-on-unregister

Home Terms Privacy Docs