Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asyncio task hang during connection attempt #1591

Open
mlaz opened this issue Jun 3, 2024 · 1 comment
Open

Asyncio task hang during connection attempt #1591

mlaz opened this issue Jun 3, 2024 · 1 comment
Labels
Backend: BlueZ Issues and PRs relating to the BlueZ backend more info required Issues does not have a reproducible test case, has insufficent logs or otherwise needs more feedback

Comments

@mlaz
Copy link

mlaz commented Jun 3, 2024

  • bleak version: 0.21.1 (also seen with 0.22.1)
  • dubs-fast version: 2.12
  • Python version: 3.11
  • Operating System: Linux 6.0.16 (also tested w kernel 5.15.0)
  • BlueZ version (bluetoothctl -v) in case of Linux: 5.69

Description

Every time there is an attempt to connect to a device and during this attempt the device disappears, the task performing the attempt to connect hangs.
We found an uncaught asyncio.exceptions.CancelledError on dbus-fast/aio/message_bus.py on the implementation of the call method, where it awaits for a reply to the performed d-bus call.
We quickly fixed this by catching this exception on dbus-fast.
Even though this exception gets caught and raised, and later caught in bleak client.py it still hangs.

What I Did

We implemented a program that scans using a characteristic filter, periodically during 5sec.
At the end of each scanning period it sorts and filters a list of devices based on the average RSSI values(and some other calculations) and attempts to connect to some of them.
This connection is done to one device at a time, and of course after disabling the scanner (also passing the BLEDevice to the BleakClient constructor). We did implement a few variations, one of them spawns one task per device, using a lock whenever we are either connecting+subscribing to characteristics, another just attempts to connect inside the same task that scans.
Both approaches work quite well, unless one of the target devices disappears during the connection attempt, as described previously.

Logs

We will soon provide a code sample with a similar implementation to what we have and corresponding logs so we can provide a clean output and not expose information that is inherent to our application.

@dlech
Copy link
Collaborator

dlech commented Jun 3, 2024

Can you provide a minimal reproducible test case and logs showing timing of when connections are started and completed along with the full stack trace of the error?

@dlech dlech added Backend: BlueZ Issues and PRs relating to the BlueZ backend more info required Issues does not have a reproducible test case, has insufficent logs or otherwise needs more feedback labels Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backend: BlueZ Issues and PRs relating to the BlueZ backend more info required Issues does not have a reproducible test case, has insufficent logs or otherwise needs more feedback
Projects
None yet
Development

No branches or pull requests

2 participants