[AJHH24]

Summary

On Linux the app often fails to reconnect after the earbuds go back in the case and come out again: BlueZ shows them connected and audio plays, but the app stays disconnected until it is restarted. The log shows the auto-reconnect never runs, only:

Exception: System.InvalidOperationException: An attempt was made to transition a task to a final state when it had already completed.
   at System.Threading.Tasks.TaskCompletionSource`1.SetResult(TResult result)
   at ThePBone.BlueZNet.Extensions.<>c__DisplayClass5_0`2.<WatchPropertyValueAsync>b__0(PropertyChanges propertyChanges)

Cause

WatchPropertiesAsync returns Task<IDisposable>. Because Task is itself IDisposable, the ret is IDisposable check in WatchForPropertyChangeAsync and WatchPropertyValueAsync stores the task as the watcher, so Dispose() disposes the task and never removes the D-Bus match. As a result:

• every connect leaks a Connected watchdog, so each disconnect is reported once per earlier connect (the log shows Linux.BluetoothService: Disconnected twice after two connects);
• every WaitForPropertyValueAsync leaks a watcher whose TaskCompletionSource already completed. On the next reconnect it calls SetResult again, the exception escapes the signal handler (the catch calls SetException, which throws too), and the handler that would have triggered ConnectionWatcherCallback never runs.

Change

• Wrap the returned Task<IDisposable> so disposing the watcher disposes the real subscription once it is available.
• Use TrySetResult/TrySetException so a repeated property change cannot throw.
• Dispose the watcher on the timeout path as well.

Testing

Linux (Arch, BlueZ), Galaxy Buds4 Pro. Disconnect/reconnect twice in a row with bluetoothctl, then the real case: buds in the closed case until they drop, then out. Each disconnect is now logged once, Reconnected. Attempting to auto-connect to profile... follows every reconnect, and no exception is thrown.