Open Bug 1485703 Opened 6 years ago Updated 2 years ago

Discuss removing addonDetails (or extending activeAddons)

Categories

(Toolkit :: Telemetry, enhancement, P3)

enhancement
Points:
2

Tracking

()

Tracking Status
firefox63 --- affected

People

(Reporter: Dexter, Unassigned)

References

(Blocks 3 open bugs)

Details

The main ping is reporting "addonDetails" (which reports the ids of inactive addons in addition to active ones), but there shouldn't be many consumers to this field. We do have "activeAddons", which only report info about the active addons, even though each entry has a "disabled" property which is always false.

We should:

- check if anyone is still using addonDetails
-- if so, provide an alternative through activeAddons
- remove addonDetails
- remove the "disabled" property from the reported data in activeAddons
Blocks: 1201022, 1121527
Hey Martin! TAAR was using the addonDetails field to get a list of inactive addons from the users in the HBase instance. As far as I know, we don't have an hbase instance anymore and we have no job using this property anymore. Can you confirm that TAAR is no longer using this field? We're planning to clean up stuff (= remove it :) ).
Points: --- → 2
Flags: needinfo?(mlopatka)
Priority: -- → P3
Blocks: 1438873
I can confirm that the HBase job has been depricated in favour of a dynamoDB implementation.

TAAR makes use of the `activeAddons` when filtering clients data for the similiarity_job to ensure that recommendation models are not boased towards installed but disabled addons. I do not know the utulity of this in terms of how often an installed but disabled addon is removed.

However, we are currently migrating the ETL jobs to use clients daily which in turn is being updated to hold more fields for us to use. 

See https://bugzilla.mozilla.org/show_bug.cgi?id=1485152

Another person to check with is :bmiroglio who is doing analytical work on product/addon topics and I know we ahve had some dicsussions about client interaction with the disable/remove functionality.

also adding vng in cc as he has been involved in the TAAR ETL job refactoring effort and may have additional insight into our current usage of both `activeAddons` and `addonDetails`.
Flags: needinfo?(vng)
Flags: needinfo?(mlopatka)
Flags: needinfo?(bmiroglio)
I don't regularly use the addonDetails field, but it is nice having a list of disabled add-ons somewhere for special cases e.g. we disable a malicious add-on and are assessing the % of clients affected.

I'm OK with adding these to the activeAddons field with the disabled flag turned on. It will break the `addon_aggregates` dataset and the reports that rely on it, however this can be backfilled and any immediate effect should be minimal.
Flags: needinfo?(bmiroglio)
edit: `addon_aggregates` relies on main_summary, so we'd need to catch this in the next main_summary backfill if we go that route.
We don't use `addonDetails` at all for our dynamoDB job, so I'm ok with removing this field.
Flags: needinfo?(vng)

Prior to any removal I'd like a conversation that includes someone on the addon team as well. We've been needing data and I've been shown yet a third set of data I was unaware of. Also, activeAddons does not include language packs, dictionaries, etc.

payload.info.addons
payload.addonDetails (nightly only, but same as above)
activeAddons

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.