bug 1440673 - Allow scalar keys to be an extra 2 chars long r?Dexter draft
authorChris H-C <chutten@mozilla.com>
Tue, 27 Mar 2018 16:15:27 -0400
changeset 777934 ff68bf2d34edbcdcdeb3e77b02bf0580017eb498
parent 777933 54668f4982a9100a4108c5d6a20f56800ea593e2
child 777935 53e79ffd8aa5abbd6c7f00a69111359ac833d9e3
child 778098 2bc1bfe0ef2a8b5d7f30052dbd15015abfad034e
push id105342
push userbmo:chutten@mozilla.com
push dateThu, 05 Apr 2018 15:24:31 +0000
reviewersDexter
bugs1440673
milestone61.0a1
bug 1440673 - Allow scalar keys to be an extra 2 chars long r?Dexter This allows us to store Telemetry Event category (30), method (20), object (20), and two delimiters (2) in a single key, like so: oohwowlookthiscategoryissolong#thismethodislongtooo#thisobjectisnoslouch MozReview-Commit-ID: BkoU1VAXFF9
toolkit/components/telemetry/TelemetryScalar.cpp
toolkit/components/telemetry/docs/collection/scalars.rst
--- a/toolkit/components/telemetry/TelemetryScalar.cpp
+++ b/toolkit/components/telemetry/TelemetryScalar.cpp
@@ -83,17 +83,17 @@ namespace TelemetryIPCAccumulator = mozi
 ////////////////////////////////////////////////////////////////////////
 ////////////////////////////////////////////////////////////////////////
 //
 // PRIVATE TYPES
 
 namespace {
 
 const uint32_t kMaximumNumberOfKeys = 100;
-const uint32_t kMaximumKeyStringLength = 70;
+const uint32_t kMaximumKeyStringLength = 72;
 const uint32_t kMaximumStringValueLength = 50;
 // The category and scalar name maximum lengths are used by the dynamic
 // scalar registration function and must match the constants used by
 // the 'parse_scalars.py' script for static scalars.
 const uint32_t kMaximumCategoryNameLength = 40;
 const uint32_t kMaximumScalarNameLength = 40;
 const uint32_t kScalarCount =
   static_cast<uint32_t>(mozilla::Telemetry::ScalarID::ScalarCount);
@@ -917,17 +917,17 @@ internal_LogScalarError(const nsACString
       break;
     case ScalarResult::StringTooLong:
       errorMessage.AppendLiteral(u" - Truncating scalar value to 50 characters.");
       break;
     case ScalarResult::KeyIsEmpty:
       errorMessage.AppendLiteral(u" - The key must not be empty.");
       break;
     case ScalarResult::KeyTooLong:
-      errorMessage.AppendLiteral(u" - The key length must be limited to 70 characters.");
+      errorMessage.AppendLiteral(u" - The key length must be limited to 72 characters.");
       break;
     case ScalarResult::TooManyKeys:
       errorMessage.AppendLiteral(u" - Keyed scalars cannot have more than 100 keys.");
       break;
     case ScalarResult::UnsignedNegativeValue:
       errorMessage.AppendLiteral(u" - Trying to set an unsigned scalar to a negative number.");
       break;
     case ScalarResult::UnsignedTruncatedValue:
--- a/toolkit/components/telemetry/docs/collection/scalars.rst
+++ b/toolkit/components/telemetry/docs/collection/scalars.rst
@@ -169,17 +169,17 @@ Optional Fields
 
 String type restrictions
 ------------------------
 To prevent abuses, the content of a string scalar is limited to 50 characters in length. Trying
 to set a longer string will result in an error and no string being set.
 
 Keyed Scalars
 -------------
-Keyed scalars are collections of one of the available scalar types, indexed by a string key that can contain UTF8 characters and cannot be longer than 70 characters. Keyed scalars can contain up to 100 keys. This scalar type is for example useful when you want to break down certain counts by a name, like how often searches happen with which search engine.
+Keyed scalars are collections of one of the available scalar types, indexed by a string key that can contain UTF8 characters and cannot be longer than 72 characters. Keyed scalars can contain up to 100 keys. This scalar type is for example useful when you want to break down certain counts by a name, like how often searches happen with which search engine.
 
 Keyed scalars should only be used if the set of keys are not known beforehand. If the keys are from a known set of strings, other options are preferred if suitable, like categorical histograms or splitting measurements up into separate scalars.
 
 Multiple processes caveats
 --------------------------
 When recording data in different processes of the same type (e.g. multiple content processes), the user is responsible for preventing races between the operations on the scalars.
 Races can happen because scalar changes are sent from each child process to the parent process, and then merged into the final storage location. Since there's no synchronization between the processes, operations like ``setMaximum`` can potentially produce different results if sent from more than one child process.