1485885 - Add telemetry for firefox commands

Status: RESOLVED DUPLICATE of bug 1583897

(Firefox :: Sync, enhancement, P2)

Description

[Mark Hammond [:markh] [:mhammond]]

We currently have telemetry to measure "old sendtab" usage and success, but do not have the same telemetry for firefox commands. We should get this in asap to be sure the feature is working as we expect.

Comment 1

[Leif Oines [:loines]]

Is there a doc/buglist anywhere that I can look at for a summary of the work that's planned and/or been done?

Comment 2

[Mark Hammond [:markh] [:mhammond]]

(In reply to Leif Oines [:loines] from comment #1)
> Is there a doc/buglist anywhere that I can look at for a summary of the work
> that's planned and/or been done?

Not really. There's bug 1453855, but that has nothing useful.  I'll try and explain what we have now:

* sendTab obviously has 2 parts - a sending device and a receiving device. Both these devices record an "event" in the sync ping.

* The sender sends an event with .object="sendcommand" and .method="displayURI".

* The receiver sends an event with .object="processcommand" and .method="displayURI".

* Both events have in .extra a "flowID" field with a GUID - the GUID is the same on both sender and receiver.

* Both events have in .extra a "deviceID" field, which is the device ID of the "other device" (ie, the sender records the device ID of the receiver and vice-versa)

So this is a little tricky to process:

1) We want to start by finding a ping with a "sendcommand" - that will give us flowID and the ID of the device we are sending the URL to. We then need to look at all pings submitted by the device we are sending to, and find a "processcommand" with the same flowID - we then know that sendtab was successful.

2) If we find a "sendcommand" with no corresponding "processcommand", then in theory, the sendtab failed - the receiving device never saw it.

3) It should be impossible to find a "processcommand" with no corresponding "sendcommand" - but we do! So that implies something is wrong with the telemetry, such as pings going missing - which means there must also be doubt cast on (2) - if we can randomly lose one of the 2 events, we seem just us likely to randomly lose the sending event as the receiving one, meaning (2) is measuring a combination of the success of the feature and the success of our telemtry!

I previously knocked up https://gist.github.com/mhammond/ff2982f9bc5c88d23000d58f18d21517, although I think this can be better done in redash. This is only showing a 70% success rate, but anecdotally, I think it works more reliably than that. It also shows (3) above, so it casts doubt on these figures in general.

So now, just to complicate things, we have "Firefox Commands" - this will be using a different mechanism entirely to send and receive commands - but only in *some* cases. So we need:

* This new process should send similar telemetry as the old process - ISTM that it should send identical events, although with something new in .extra to identify it is the new process rather than the old process.

* We want to build up dashboards which takes the new process into account, and ideally see if that performs better, and see if it has the same apparent loss of data we see today.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

This is being done in bug 1583897