Add a per-sync UUID for telemetry

[linabutler]

This work will almost certainly happen in a-c, not here, but filing the bug here so it shows up in our tracking tools! 🚀

One of the things that came up in the Glean // Sync meeting is, how do we report sync-level errors, and other sync-level (or ping-level) data like device info? Currently, we push those down into the per-engine pings, and have a workaround in a-c to avoid sending multiple pings with the same top-level error. We also don't have a way to correlate different engines from the same sync.

We can make this easier by tagging each Glean ping with a "sync UUID"—though let's come up with a better name because "sync ID" means many different things! 😆 This would give us a column on which to join the history_sync, bookmarks_sync, etc. tables.

In the short term, the sync UUID will lets us correlate engines that were synced as part of the same sync. In the long term, this can be a stepping stone to having a sync_errors (or maybe even syncs) ping, to report top-level errors and other stats. The long-term part can happen in a separate bug. 😁

┆Issue is synchronized with this Jira Story

[rfk]

Random thought, I wonder if it would be useful to use an orderable identifier here (something like snowflake or a "ULID" or similar) rather than an ordinary UUID. Probably not that helpful for telemetry, but I'm imagining us including this identifier in other log output in future, where it might be useful to be able to tell what order different sync attempts occurred in.

Not sure if there would be any privacy implications though.

[Dexterp37]

I'm imagining us including this identifier in other log output in future, where it might be useful to be able to tell what order different sync attempts occurred in.

If you need to do that in the analyses, please note that all glean pings, including custom pings, do have a start_time.

[linabutler]

@grigoryk did this in mozilla-mobile/android-components#5386, so no need for us to track it here!

That's a good suggestion, @rfk! We end up relying on timestamps in logs to try and reconstruct what happened, which makes things harder.

If there was a way to make these consistent across devices (sort of like a vector clock? or we could send the ULID up to the sync server, and correlate those with client logs), we could see which device synced in which order, and when—which, on the one hand, would be super valuable for tracking down consistency issues, but, on the other hand, might have even bigger privacy implications.

[jdragojevic]

sounds like done.