Bugzilla

Metrics are recorded in different stores based on their lifetimes. Within a single lifetime store, metrics are additionally persisted partitioned by the 'storage name' (i.e. the ping they will end up in) and metric id.

When changing the type of a metric, the metric id will remain the same, since the metric identifier is made up of its category and the metric name.

This implies that the Glean SDK will face some data-loss scenarios if the the type of a metric changes, but the lifetime and the container ping name stay the same.

| Lifetime change | Store change | Outcome |
|-----------------|--------------|----------------------------------------------------------------------------------------------------------------------------------|
| Y | N | No data loss. Depending on the old and new lifetime, data from both the metric type may be sent in the same ping. |
| Y | Y | No data loss. The new ping will contain only the data from the new type. The old ping/store will contain data from the old type. |
| N | Y | No data loss. The new ping will contain only the data from the new type. The old ping/store will contain data from the old type. |
| N | N | Some data loss. The ping will contain only the data from the new type even if some data was previously stored with the old type. |

The following is a breakdown of the different data-loss scenarios:

## Ping lifetime

### If `delay_ping_lifetime_io` is active

- there was a prevously stored value: if the [transform function](https://searchfox.org/glean/rev/fa584f1b1e6732d6c157f4dc9cf699e7e746d13a/glean-core/src/database/mod.rs#382) uses the previous stored value, the result depends on how the metric type handles faulty old values;
- no prevously stored value: nothing odd happens

### If `delay_ping_lifetime_io` is inactive

- there was a prevously stored value: depends on the [transform function](https://searchfox.org/glean/rev/fa584f1b1e6732d6c157f4dc9cf699e7e746d13a/glean-core/src/database/mod.rs#397) as well.
- no prevously stored value: nothing odd happens

## Other lifetimes
The behaviour is similar to the `ping` lifetime, without the distinction for the delayed I/O.

@Jan-Erik, does the above make sense given your knowledge of the core part?
@Mike, assuming the above is correct, I think there's minimal chance for unexpected data loss. Ideally, that would only really be an issue for `user` lifetime metrics that changed the type (other lifetimes are, in theory, shorter so even if there's data loss it would be less dramatic).

This seems like something that should rather be addressed through documentation. Thoughts?

Metrics are recorded in different stores based on their lifetimes. Within a single lifetime store, metrics are additionally persisted partitioned by the 'storage name' (i.e. the ping they will end up in) and metric id.

When changing the type of a metric, the metric id will remain the same, since the metric identifier is made up of its category and the metric name.

This implies that the Glean SDK will face some data-loss scenarios if the the type of a metric changes, but the lifetime and the container ping name stay the same.

| Lifetime change | Store change | Outcome |
|-----------------|--------------|----------------------------------------------------------------------------------------------------------------------------------|
| Y | N | **No data loss**. Depending on the old and new lifetime, data from both the metric type may be sent in the same ping. |
| Y | Y | **No data loss**. The new ping will contain only the data from the new type. The old ping/store will contain data from the old type. |
| N | Y | **No data loss**. The new ping will contain only the data from the new type. The old ping/store will contain data from the old type. |
| N | N | **Some data loss**. The ping will contain only the data from the new type even if some data was previously stored with the old type. |

The following is a breakdown of the different data-loss scenarios:

## Ping lifetime

### If `delay_ping_lifetime_io` is active

- there was a prevously stored value: if the [transform function](https://searchfox.org/glean/rev/fa584f1b1e6732d6c157f4dc9cf699e7e746d13a/glean-core/src/database/mod.rs#382) uses the previous stored value, the result depends on how the metric type handles faulty old values;
- no prevously stored value: nothing odd happens

### If `delay_ping_lifetime_io` is inactive

- there was a prevously stored value: depends on the [transform function](https://searchfox.org/glean/rev/fa584f1b1e6732d6c157f4dc9cf699e7e746d13a/glean-core/src/database/mod.rs#397) as well.
- no prevously stored value: nothing odd happens

## Other lifetimes
The behaviour is similar to the `ping` lifetime, without the distinction for the delayed I/O.

@Jan-Erik, does the above make sense given your knowledge of the core part?
@Mike, assuming the above is correct, I think there's minimal chance for unexpected data loss. Ideally, that would only really be an issue for `user` lifetime metrics that changed the type (other lifetimes are, in theory, shorter so even if there's data loss it would be less dramatic).

This seems like something that should rather be addressed through documentation. Thoughts?