-
Notifications
You must be signed in to change notification settings - Fork 33
[WIP] Fix/retry refresh on exception #49
base: master
Are you sure you want to change the base?
Conversation
_connectSignal is overwritten by `Utils.addSignalsHelperMethods`
Sometimes the already instantiated bluetooth client goes into a weird state where it does not communicate with the bluez daemon anymore. This change forces the recreation of the client when it fails to refresh
Are there some easy steps to reproduce it? I am using Fedora 35 since beta and never noticed that problem (I go into suspend mode every day). Getting adapter and devices methods are copy pasted from gnome shell code. Maybe I missed something?
and
Some maybe it would be enough to refresh on those signals? I don't know what are they responsible for 😄 |
The issue always happened after Suspend/resume and after leaving the screen locked for some time
Hmmm so I my have a cursed installation :/
I'll take a look if this signal is fired here
This one you bind to refresh() in
I'll test and let you know |
BTW, this is NOT GOOD TO MERGE I've just unlocked my screen and it's stuck in a refresh loop :( |
Left the computer locked during lunch. When I came back, the keyboard was still paired, so I entered my password on the bt keyboard. Soon afterwards, I noticed that the extension was missing all the devices. Did not see the message I added on rfkill's
|
Maybe related: https://bugs.archlinux.org/task/72540 -- someone reporting that bluez disconencted after using bluetoothctl -- exactly what the extension does upon initialization. EDIT: ltracing |
Just chiming in to say that I also see this issue where I would get an error popup regarding bluetoothctl and from there, the extension no longer works. I am running Archlinux. |
After upgrading to Fedora 35, I've noticed that after suspension or long periods with the screen locked, the extension would not reload properly -- no device would show in the menu.
I have observed that on such occasions there would be some message like
Could not create bluez object manager: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected
Further debugging has shown that
bluetooth.service
restarts withDisconnected from D-Bus. Exiting.
BluetoothController::_getDefaultAdapter
would return nullThe restarting of bluez seems to happen every suspend/resume and when the screen remains locked for some time.
It seems to be a race condition where the extension instantiates a client that holds a reference to an instance that's about to be killed, and the client does not check the bus for a new instance afterwards.
I implemented this workaround that tries to reconnect on such occasions, but I'm not very happy with it... what happens when the daemon restarts mid-session? Will the extension receive any signal that can eventually trigger a
refresh
?(a few tests here have shown that the client will happily point to the new instance in this last case and behaves normally)
I left the MR in [WIP] to discuss if there's some more robust sollution.