Open Bug 1979681 Opened 2 months ago Updated 2 months ago

Quantity metric docs don't document the upper limits

Categories

(Data Platform and Tools :: Glean: SDK, defect, P4)

defect

Tracking

(Not tracked)

People

(Reporter: janerik, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [docdays])

The quantity metric docs don't document the upper limits of what the metric type allows.
Compare that to a counter metric which documents it as 32-bit signed integer.

It should be 64-bit signed integer (see API definition).

A fun back'n'forth in the team about this bug:

  • On one hand, we don't need to document this limit because the API accepts, stores, and reports any (non-negative) value that the type system will allow to be supplied. It takes an i64, stores an i64, and reports an i64 (technically those are all u63 in practical terms because of the invalid_value error and behaviour for values < 0, but you get the idea)
  • On the other hand, Python (and in FOG, JS) do not have types that permit this level of guarantee.
  • On some secret third hand, if we do document and enforce the limit, what do we say about the errors that are generated if a value out of bounds is supplied? The Rust core cannot receive a value outside of the type guarantee, and without bug 1691073, language bindings can't supply the metric error themselves (FOG will silently clamp because of webidl's handling of integer type conversion)
Depends on: 1691073
Priority: P3 → P4
Whiteboard: [telemetry:glean-rs:m?] → [docdays]
You need to log in before you can comment on or make changes to this bug.