BLE Advertisement Unregistration: "Advertisement does not exist" |
||||
Issue descriptionThe InstantTethering.BluetoothAdvertisementUnregistrationResult metric tracks the success/error codes which occur when a Bluetooth advertisement is unregistered: https://uma.googleplex.com/p/chrome/histograms?endDate=latest&dayCount=7&histograms=InstantTethering.BluetoothAdvertisementUnregistrationResult&fixupData=true&uniqueUsers=true&showMax=true&filters=platform%2Ceq%2CC%2Cchannel%2Cone_of%2C4%7C3%7C2%7C1%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial 35% of all attempts to unregister an advertisement fail with the error device::BluetoothAdvertisement::ErrorCode::ERROR_ADVERTISEMENT_DOES_NOT_EXIST. However, only ~1% of users see this error. It seems that when that 1% see the error, it keeps failing forever and dilutes our metrics. This error code is strange because it occurs due to calling Unregister() on a device::BluetoothAdvertisement object which has not been unregistered. If we encounter this error code, should we just assume that unregistration succeeded? If not, what is the correct thing to do?
,
Feb 8 2018
Rahul, could it be the same as what this CL is trying to fix: https://chromium-review.googlesource.com/c/chromium/src/+/741261
,
Feb 8 2018
That seems reasonable as well, Sonny. How about this approach: (1) Sonny gets that CL reviewed, which should hopefully fix the root cause of the issue. (2) In Instant Tethering code, we consider the unregistration successful if we hit this case.
,
Feb 8 2018
,
Feb 8 2018
Due to our bluez hack in UnregisterAdvertisement, that interface may fail and needs to be retried. So, magic tether should retry if that fails, unless magic tether wants to detect bluetooth adapter gone event and treat UnregisterAdvertisement as success. I think we should fix the bluetooth stack only.
,
Feb 8 2018
Hmm, if we get that error type, should we really retry? It seems that if the system thinks that the advertisement is no longer registered, we should not continue trying to unregister.
,
Feb 8 2018
Having an API that can fail and requires client to retry is a pain. Unfortunately it's not possible to make the API always succeed because it requires a massive re-architecting of bluez. When we move to newblue hopefully this API can have a success guarantee so that client doesn't need to worry about retry.
,
Feb 8 2018
Ah, you are saying that you can detect this particular case by the error code. Yes, if the error code is reliable you may do that.
,
Feb 14 2018
This was fixed by https://chromium-review.googlesource.com/c/chromium/src/+/915132 (the CL author forgot to include a "Bug:" line on the CL).
,
Sep 26
|
||||
►
Sign in to add a comment |
||||
Comment 1 by r...@chromium.org
, Feb 8 2018