GATT operation in progress - how to handle it?

[perja12]

I have a web page that writes to a characteristic, but if I do this too fast, I will get the error "GATT operation in progress". Is this something the page author should handle or should the implementation take care of queuing the requests?

If it is the page author, it will be good to include some recommendations for how to handle this. AFAIK there is no way to query the state of the implementation other than responding to the errors.

[beaufortfrancois]

Are you testing this on Chrome OS or Android?

[perja12]

Testing this on Android (Chrome Dev build) and soon in Opera internal build.

[beaufortfrancois]

I believe this issue has been fixed recently (https://codereview.chromium.org/1465863003/).
You may want to try with the latest Chromium build at https://download-chromium.appspot.com/?platform=Android and let me know if you're still experiencing this.

[perja12]

Tested the latest Chromium and the crash when "GATT operation in progress" occurs has been fixed - so that is good.

But my main question is still open: is it the responsibility of the page author to handle "GATT operation in progress" or should this be handled by the implementation? There seems to be pros and cons with both approaches.

[beaufortfrancois]

Glad to hear that.

Hopefully @g-ortuno @scheib or @jyasskin will be able to fully answer your question here.

[jyasskin]

The implementation's supposed to handle it, but we don't yet (https://crbug.com/560862). @scheib has argued that we should make the web page handle it instead, in which case the rule would be that you wait for the writeValue() Promise to settle before calling writeValue() again. If there's a good reason you can't do that, it would probably settle the argument.

[scheib]

We should keep the implementation flexible, and not force queuing if the application doesn't desire it.

12:35 AM Hi, short question about web-bluetooth: I have a page that writes to a characteristic whenever a button is pressed (or actually a touch event), but if I click to fast I get the "GATT operation in progress"-error. Is it so that the page author is supposed to handle this with a queue or similar, or will the implementation do the queing?
1:12 AM perja: Currently unspecified. We should pick and make it clear. Some devices may be fairly slow to accept a write. What should happen if the web page can generate write requests at 2 times the speed a device can process them? If the browser queues, should it pick any limit for how large the queue should get? An application can know if a queue of unlimited values is needed or if only 1 pending value needs to be queued and replaced if a newer value arrives.

[pzboyz]

Truly low power devices will be setting connection intervals of +100ms, and it is highly likely that only one GATT operation may be handled per connection interval, arguably the page author does not need to know the GATT operations have entered a queue, but it will need to know which ones have been executed. Imagine a case where the web page has written to a characteristic expecting the device behaviour to change, if that operation is 4th in the queue, the device may still send notification indicating it is still performing with the previous old behaviour, what is the web page to do given that it thinks the GATT operations have already been sent?

[jyasskin]

When the web page wants to know which writes have completed, it needs to attach a handler to the Promise returned by writeValue(). If the implementation doesn't queue, every use of writeValue needs to be handled like this, while if we do queue, sites that don't care about latency (e.g. sites that only write in response to a user gesture, and for which the device itself gives feedback that the operation is finished) can write simpler code.

[g-ortuno]

I think we should keep the implementation as simple as possible for now. Writing a library/polyfill to queue GATT operations is fairly trivial and would allow us to iterate faster if unforeseen problems arise.

[LeonNicholls]

Agree with @scheib about keeping the implementation flexible. It is easy enough to wait for fast write operations and not all apps need to have queuing.

[jyasskin]

SG. In order to write the queuing library, we'd need to guarantee that two separate tabs using Bluetooth concurrently, or a tab and an extension/app, or a tab and the OS, couldn't cause the tab to see an in progress error. Is that something the implementation can guarantee with simpler code than just queuing everything?

[g-ortuno]

We don't get any signals from the system that the there is an operation in progress. Which also means our implementation of queuing couldn't guarantee no in progress errors since a Tab could get an in progress error if another App is using bluetooth.