Kyle, what is the action item of this bug?  Relatedly, your assessment of the metric is not clear to me.

Also, why is this Restrict-View-Google?

(Apologies for the vague description - this bug was created in a batch after Ryan created the spreadsheet of the anomalies in our metrics.)

For EasyUnlock, we set the Chromebook's connection latency before attempting a connection. This operation is asynchronous, so we receive a callback when this operation succeeds/fails; if we never get the success or failure callback after 2 seconds, we time out and fail to set the connection latency:

https://cs.chromium.org/chromium/src/components/cryptauth/ble/bluetooth_low_energy_weave_client_connection.cc?q=SetConnectionLatency

The action item is to investigate why this is occurring and to fix the issue. It's likely that this issue occurs lower in the stack than Chrome, so you'll need to work with the Bluetooth team (cc'ed) to arrive at a solution. We've generally applied Restrict-View-Google on bugs where we link to our metrics.

Re: Metrics and RVG. What is the rationale?  Corp links aren't inherently bad (in fact they're everywhere).

> we set the Chromebook's connection latency before attempting a connection.

Wait, what? connection latency is a property of a connection not of a device.

@jhawkins: Gotcha - makes sense, so I've removed the label.

@dmitrygr: Sorry - I misstated this earlier. However, it was my impression that the connection latency applies to the device we're communicating with, not one particular connection (since SetConnectionLatency() is an instance function of device::BluetoothDevice). Is my understanding incorrect?

At the layer of actual bluetooth, connection latency is a property of an LE connection that is settable by master at connection time, and changeable by master any other time. Slave can only request changes and master may or may not grant them.

To clarify the confusion here, the latency mentioned in #7 refers to the number of connection events allowed to be skipped by the slave and it is set by master, and this latency is used in the LE create connection command.

However, the "SetConnectionLatency" mentioned in #6 refers to a Chrome API [1] which sets the min and max connection intervals, and these intervals will be used later when making a LE connection. SetConnectionLatency will end up in kernel as MGMT_OP_LOAD_CONN_PARAM request which suppose to return without involving any HCI traffics.

@khorimoto, can you share related logs where the issue was observed?


[1]https://cs.corp.google.com/clankium/src/device/bluetooth/bluez/bluetooth_device_bluez.cc?rcl=0&l=454

@mcchou: I haven't actually observed this issue myself as it only occurs in EasyUnlock. This bug was created due to monitoring metrics. I will try to test out EasyUnlock and see if I can reproduce the issue.

Assigning to Kyle per comment 9.

I wasn't able to reproduce this issue myself, so I'm just going to close this issue out since it is a relatively rare repro. If it becomes more serious, we can re-open.