Bugzilla

Because Glean didn't support `object` metric types when the crash ping was originally created, annotations were manually translated to metrics. This is cumbersome. Ideally, a developer who wants to add an annotation can do so by simply editing `CrashAnnotations.yaml` and adding code to set the annotation. Instead, they must edit `CrashAnnotations.yaml` (some code paths will still use it for various purposes besides the legacy ping), the desktop and/or android `metrics.yaml` glean definitions, and the desktop/crashreporter client code to populate the metrics and/or the android client code to populate the metrics (all in different languages!).

There are a few solutions to this problem:
* Bug 1911301 would do a lot to mitigate the overhead here by centralizing the conversion code in one place and in one language. That would arguably help out a lot: asking developers to update multiple programming languages isn't great.
* By adding a little more information to `CrashAnnotations.yaml` (where necessary), we may be able to generate the metrics files and/or conversions code.
* We could change the crash ping to use an `object` metric for annotations. This makes querying annotation information in e.g. BigQuery slightly more involved, and also removes the ability to store particular annotations in more intelligent ways (`quantity` metrics with units, string lists, etc). However, it would allow the code that stores annotations in glean metrics to be generic. We could potentially also store some things more intelligently by adding extra information to `CrashAnnotations.yaml`. `object` metrics don't allow arbitrary keys in objects, however we could use a definition like:
  ```
  type: object
  properties:
    stringAnnotations:
      type: array
      items:
        type: object
        properties:
          key: string
          value: string
    boolAnnotations:
      type: array
      items:
        type: object
        properties:
          key: string
          value: string
  ...
  ```
* Crash annotations could be stored using the glean API, dropping `CrashAnnotations.yaml` altogether. This is unlikely to be tenable since the annotation API is optimized for efficiency and for running in degraded circumstances. The API also features the ability to extract annotations from other processes, which would need to be reworked in some (likely significant) way.

Because Glean didn't support `object` metric types when the crash ping was originally created, annotations were manually translated to metrics. This is cumbersome. Ideally, a developer who wants to add an annotation can do so by simply editing `CrashAnnotations.yaml` and adding code to set the annotation. Instead, they must edit `CrashAnnotations.yaml` (some code paths will still use it for various purposes besides the legacy ping), the desktop and/or android `metrics.yaml` glean definitions, and the desktop/crashreporter client code to populate the metrics and/or the android client code to populate the metrics (all in different languages!).

There are a few solutions to this problem (numbered here for easy referencing):
1. Bug 1911301 would do a lot to mitigate the overhead here by centralizing the conversion code in one place and in one language. That would arguably help out a lot: asking developers to update multiple programming languages isn't great.
2. By adding a little more information to `CrashAnnotations.yaml` (where necessary), we may be able to generate the metrics files and/or conversions code.
3. We could change the crash ping to use an `object` metric for annotations. This makes querying annotation information in e.g. BigQuery slightly more involved, and also removes the ability to store particular annotations in more intelligent ways (`quantity` metrics with units, string lists, etc). However, it would allow the code that stores annotations in glean metrics to be generic. We could potentially also store some things more intelligently by adding extra information to `CrashAnnotations.yaml`. `object` metrics don't allow arbitrary keys in objects, however we could use a definition like:
  ```
  type: object
  properties:
    stringAnnotations:
      type: array
      items:
        type: object
        properties:
          key: string
          value: string
    boolAnnotations:
      type: array
      items:
        type: object
        properties:
          key: string
          value: string
  ...
  ```
4. Crash annotations could be stored using the glean API, dropping `CrashAnnotations.yaml` altogether. This is unlikely to be tenable since the annotation API is optimized for efficiency and for running in degraded circumstances. The API also features the ability to extract annotations from other processes, which would need to be reworked in some (likely significant) way.