What type of UMA would you like? We already have a counter for when the function is called and the callback offers no new information:

https://cs.chromium.org/chromium/src/content/browser/bluetooth/web_bluetooth_service_impl.cc?sq=package:chromium&dr=CSs&rcl=1480004359&l=890

IIRC I was wondering why OnStopNotifySessionComplete wasn't following the same pattern as OnStartNotifySessionSuccess and OnStartNotifySessionFailed and not use something like

  callback.Run(TranslateGATTErrorAndRecord(error_code, UMAGATTOperation::STOP_NOTIFICATIONS));

I think stopNotifications may fail if descriptor can't be written for some reason and that we should return a rejected promise in that case right?

Actually, per spec, we never reject. Furthermore as opposed to StartNotifySession StopNotifySession does not have success and error callbacks, it just has a completed callback which is always called.

I may misreading the spec but here's what is written at https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetoothremotegattcharacteristic-stopnotifications:

    The stopNotifications() method, when invoked, MUST return a new promise promise and run the following steps in parallel:

    1. Let characteristic be this.[[representedCharacteristic]].
    2. If characteristic is null, return a promise rejected with an InvalidStateError and abort these steps.
    ...

Right, but that is not related to the GATT operation. Regardless of the outcome of the GATT operation we always successfully resolve the promise.

I've changed bug description.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot