[peripheral] Received UpdateValue result for characteristic without a continuation

[solita-jtn]

Getting lots of "[peripheral] Received UpdateValue result for characteristic without a continuation" prints in console. This seems to slow down reads and writes, but eventually everything is working ok. The amount of prints seems to increase when disconnecting and connecting again to a device.

Has this something to do with queueing of commands? Is there are way to flush the queue?

[manolofdez]

Hi! What version of the library are you using? We recently made some changes in 1.4.0 to silence this specific error when the characteristic is notifying.

For logging we are using os.Logger, which should have a low-performance overhead. That specific log message happens after dequeueing work. I'd be surprised to see this causing slow-downs. Are you able to measure the impact of the logger?

Has this something to do with queueing of commands? Is there are way to flush the queue?

Unless there's a bug, this should only happen if you update a peripheral's characteristic without using AsyncBluetooth (e.g. using CoreBluetooth directly) while AsyncBluetooth's central manager is initialized and tracking that peripheral. There is a way to flush the queue, but it's internal to the library.

[solita-jtn]

Using 1.4.0, but the changes you are referring is not included in that. All the communication goes through AsyncBluetooth.

I see a lot of these logs when reconnecting to a device, like the queue wouldn't have been flushed when disconnected. Probably not the actual logging slows down, but processing the un-flushed queue or at least that is how it feels.

[manolofdez]

Using 1.4.0, but the changes you are referring is not included in that. All the communication goes through AsyncBluetooth.

Ah, I see. Just pushed a new release 1.4.1 with the changes.

I see a lot of these logs when reconnecting to a device, like the queue wouldn't have been flushed when disconnected. Probably not the actual logging slows down, but processing the un-flushed queue or at least that is how it feels.

The queues won't get flushed when disconnected, so if they should have their continuation. They will however get flushed on deinit (e.g. when you lose all references to the peripheral), so this could also be the cause (e.g. send a write command, remove all references to the peripheral before receiving the confirmation on the phone, then get the confirmation).

It's hard to know what's causing the issue you're seeing without looking at the code or having a set of steps to reproduce, but hopefully the latest release addresses your issue. Let me know if you're still seeing it.

[solita-jtn]

I don't find the place in the code where queues are flushed, can you please point the place for me?

I think queues should be flushed in disconnect. I don't see the reason why there should be something in queues when connecting.

[manolofdez]

I don't find the place in the code where queues are flushed, can you please point the place for me?

Flushing is currently happening in the AsyncSerialExecutor's deinit here. Heads up, I will be removing the code from this deinit in the near future since it's non-isolated and is accessing the actor's (isolated) properties.

I think queues should be flushed in disconnect. I don't see the reason why there should be something in queues when connecting.

Currently, the library is trying to do the bare minimum to support async/await, while making as little assumptions as possible. Keeping the library small allows people to use or fork it without needing to commit too much or make too many compromises. That said, I definitely see the value of flushing all queues upon disconnection.

If you're going this route, you can go to the central manager's didDisconnectPeripheral function here to add the feature. A peripheral's context contains all the executors you want to flush. The tricky part will be flushing only the ones that have been initialized, since they're all lazy and we don't want to create them if we didn't use for them.

Also note that you can always cancel any queued operations manually when a peripheral disconnects. Just wrap the peripheral.writeValue call in a Task, listen to the central manager's didDisconnectPeripheral event and cancel the Task when disconnected. This will effectively remove the operation from the queue.