Change Details

Right now events that happen to produce a url that is too long are silently dropped on the client. This causes a very counter-intuitive bias in data sometimes. At the very least we should increment a counter somewhere that tracks the number of errors for this schema. Perhaps something like `eventlogging.error.NavigationTiming.urlSize` (to complement the existing `eventlogging.schema.NavigationTiming` increment). We could do either through a dedicated Schema of sorts (which we then aggregate etc.) but this runs the risk of a loop potentially and other complications. It probably makes more sense to take a light-weight approach by hitting the statsv endpoint directly and bypass EventLogging (as to not use EventLogging to track potential problems with EventLogging).

Right now events that happen to produce a url that is too long are silently dropped on the client. This causes a very counter-intuitive bias in data sometimes. At the very least we should increment a counter somewhere that tracks the number of errors for this schema. Perhaps something like `eventlogging.error.NavigationTiming.urlSize` (to complement the existing `eventlogging.schema.NavigationTiming` increment). We could do either through a dedicated Schema of sorts (which we then aggregate etc.) but this runs the risk of a loop potentially and other complications. It probably makes more sense to take a light-weight approach by hitting the statsv endpoint directly and bypass EventLogging (as to not use EventLogging to track potential problems with EventLogging). See also: * {T112002} * {T112593}

Right now events that happen to produce a url that is too long are silently dropped on the client. This causes a very counter-intuitive bias in data sometimes. At the very least we should increment a counter somewhere that tracks the number of errors for this schema. Perhaps something like `eventlogging.error.NavigationTiming.urlSize` (to complement the existing `eventlogging.schema.NavigationTiming` increment). We could do either through a dedicated Schema of sorts (which we then aggregate etc.) but this runs the risk of a loop potentially and other complications. It probably makes more sense to take a light-weight approach by hitting the statsv endpoint directly and bypass EventLogging (as to not use EventLogging to track potential problems with EventLogging). See also: * {T112002} * {T112593}