1710424 - Should the UUID metric type reject non-RFC compliant values?

Status: RESOLVED FIXED

(Data Platform and Tools :: Glean: SDK, task, P1)

Comment 1

[Michael Droettboom [:mdroettboom]]

My concern would be if we ever started to validate UUIDs in BigQuery we could be in trouble... Maybe we should at least document this so data platform doesn't ever make such a change.

Comment 2

[Chris H-C :chutten|RustWeek (Back May 25)]

I'm in favour of not doing this for the existing uuid metric type, but instead framing this as perhaps an evolution of the type.

(( rabbithole: We could force the old ones to migrate to have a strict: false param (or more descriptively rfc4122_compliant_values_only: false) on the next schema version++ (or major SDK version++) ))

We internally rely on the behaviour of it being able to hold any 8-4-4-4-12 value (though we're careful to only generate valid v4) for client_info.client_id for at least the magic c0ffee id.

Comment 3

[Jan-Erik Rediger [:janerik]]

So for documentation purposes:

We use the UUID type to store legacy data from legacy Telemetry.
That data is in UUID format (8-4-4-4-12), but not necessarily v4 (or v5, or another RFC'd version).
We get the data in ClientID.jsm, which calls platform specific code in nsUUIDGenerator.cpp, and that doesn't give any guarantees.

We only generate v4 UUIDs in glean-core as well as the c0ffeec0-ffee-c0ff-eec0-ffeec0ffeec0 id (itself not a v4 version).

For now just keeping that behavior and not bothering to do further validation, strictness check, etc. seems absolutely fine.
Not sure where to document it though.

Comment 4

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/glean/pull/1673

Comment 5

[Jan-Erik Rediger [:janerik]]

badboy merged PR #1673: "Bug 1710424 - Document more precisely how the UUID type behaves" in 7055e5a.