Currently FHR only submits data for providers that are currently registered with the data collection system. This is mainly to guard against inconsistent output due to the abuse of the types system and custom serializers. With Telemetry Experiments, we want unloaded experiments to still submit data. This will require data from unloaded providers (providers will exist in the experiment XPI) to be emitted in the payload.

Per bug 974024 comment 11, this is not a requirement for v1, and may become moot later if we can pull off incremental upload the way I hope we can.

So the context doesn't get lost... Unlike comments in bug 974024, this can likely be done without a schema bump. Two valid choices: 1) Have data belonging to unknown providers use a default/base provider instance for serializing. 2) Define types properly in the database. #1 will see all data in the DB serialized in the payload. But if a common serializer was used, that data won't be formatted consistently depending on whether the provider is initialized. #2 doesn't have this problem. It requires all custom types to have a well-defined serializer that isn't implemented as part of the provider. Really the only custom type we should need (at least short term) is JSON. Currently, we stuff JSON data for add-ons in a text field and have custom code in the provider that knows the text is really JSON. If we had a JSON type for a field, we could move this logic into the base provider and get consistent serialization regardless of provider presence. Also, I'm not sure how incremental upload solves this problem. We still need to store 180 days of history locally so about:healthreport works when data upload is disabled. I suppose we could change about:healthreport to operate on a set of incremental payload fragments. I guess we'll cross that bridge if/when we have incremental upload.

FHR is going away per bug 1209088, we have different solutions & systems in place now.