Recording the telemetry event "fxaFailed" can itself fail

[linuxwolf]

Occasionally when recording the telemetry event fxaFailed can itself fail. From instances where this failure occurs, it appears that a fxa_uid extra key is included but the registration only permits the extra key message.

The fxaFailed event can occur for some of the following reasons:

• The user aborts signing in (by closing the popup window before successfully signing in)
  • no fxa_uid present
• A network failure occurs between the user completing the FxA authentication step and the background user profile retrieval
  • no fxa_uid present
• Encryption keys for the user have changed (i.e., the user has reset their FxA password, or have just signed in as a different user)
  • fxa_uid now present

[linuxwolf]

@irrationalagent @mozilla-lockbox/engineering @mozilla-lockbox/product-integrity

There's a couple of directions I can see taking here:

• add fxa_uid to the permitted extra keys to fxaFailed (personal preference)
• separate the failure points in smaller discrete chunks (which may require additional telemetry events?)

[irrationalagent]

Thanks for catching this! If there was a way to catch different types/stages of failures, (e.g. userAbortedSignin, etc), I suppose that would be useful for us to know. However for the time being, it seems like your option #1 above might be the quickest short-term fix.

Let's think on the usefulness of adding events for the various situations in which the fxa registration flow can break. I can see a future in which they might be helpful for diagnosing problems or tweaking the UX for the signin/reg process.

[linuxwolf]

Thanks for catching this! If there was a way to catch different types/stages of failures, (e.g. userAbortedSignin, etc), I suppose that would be useful for us to know. However for the time being, it seems like your option #1 above might be the quickest short-term fix.

I think we can, but the question is how useful are different events versus making more/better use of the existing event's extras. Errors that the extension (will) use are categorized via a machine-readable string, and that categorization is prepended to the error message and available as a separate property. We can rely on the existing schema, or tweak it to apply the additional categories, or really have separate events.

Let's think on the usefulness of adding events for the various situations in which the fxa registration flow can break. I can see a future in which they might be helpful for diagnosing problems or tweaking the UX for the signin/reg process.

There are a couple of knobs we have here, and it may be a question of which knobs we want to tweak -- separate events and/or additional keys.

It is also important to note fxaFailed is recorded in two separate flows today:

• account_upgraded when the user first links their FxA to Lockbox
• signin when the user is "unlocking" Lockbox via FxA

For both of those flows, the failure points mentioned in the issue description at the top apply.