Metric "ProximityAuth.BluetoothGattNotifySessionResult" regressed on Dev |
||||
Issue descriptionSee Eve-specific metrics here: https://uma.googleplex.com/timeline_v2?sid=15cd003914acc51f86849a80507e2f33 This is caused by a rise in the "Error: Unknown" bucket: https://uma.googleplex.com/timeline_v2?sid=3e52cb6bdc608b6111e2dde1a642f0ce This trend is visible even when unique user counting is enabled, implying that this is not just affecting a few devices: https://uma.googleplex.com/timeline_v2?sid=40b873cc01cc7bdaa5946dad8c166906 This metric has also seen wild swings in Beta channel, but thankfully not Stable: What's going on here? Bluetooth team, are there any known issues that may be causing this?
,
May 31 2018
Hi Joseph, this regression seems to now be affecting Eve on Beta [1] and other boards on Stable [2]. Does this confirm your conjecture? Does more action need to be taken on this bug? 1) https://uma.googleplex.com/timeline_v2?sid=70dd56e7379b03e72941b53a5daad424 2) https://uma.googleplex.com/timeline_v2?sid=57cd950508e4504a11734ae2c17f1aca
,
Jun 1 2018
Yes, this is expected. There may be some issue in Chrome API. It seems that Miao is going to look into it soon. Miao, could you take over this issue? Thanks.
,
Jun 1 2018
Miao will look into the issue 847628 "Chrome should not call StartNotifySession() when device is disconnecting" which is expected to solve the regressions here. Let this issue block on that one.
,
Jun 5 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by josephsih@chromium.org
, May 23 2018I am not sure whether "Cannot start notification session" message in ui.LATEST caused the regression. An example log snippet looked like below. Note that there were a lot of such error logs in ui.LATEST. [1225:1225:0521/191036.412382:ERROR:bluetooth_low_energy_weave_client_connection.cc(653)] Cannot start notification session for {id: "CAESR...JMA==", addr: "5D:E5:B9:BB:69:7C"}. Error: 0. Here is my conjecture. If this caused the issue, it would soon affect all channels. I have also filed b/79327769: "Chrome may start notification on a disconnecting device" days ago with logs. That issue used to cause bluetoothd daemon crash and was thus hidden from being observed. Please refer to Issue 781076: "bluetoothd crash in register_notify_cb()". The patch to the bluetoothd crash issue landed about 1+ week ago which matches the trend. Since the bluetoothd does not crash for that reason any more, the notification session issue is exposed and the success rate drops dramatically. This was expected as the issue has been existing for a while.