Page MenuHomePhabricator

[GOAL] Tidy up EventLogging
Open, Needs TriagePublic

Description

EventLogging was the home for all code related to analytics instrumentation at WMF. It contains code relating to:

  • The so-called Legacy EventLogging system, which was superseded by the Event Platform fully in FY 24/25
  • The validation of JSONSchema schemata, whereas MediaWiki Core and very nearly all other all extensions use the justin-rainbow/json-schema or opis/json-schema libraries
  • Early attempts to introduce higher-level concepts, e.g. the mw.eventLog.Schema class
  • The Metrics Platform, including deprecated and soon-to-be-deprecated methods like mw.eventLog.dispatch() and mw.eventLog.newInstrument()

Tidying up EventLogging will help to clarify its purpose and its relationship to the Event Platform, the Metrics Platform, and Experimentation Lab.

Related Objects

StatusSubtypeAssignedTask
OpenNone
OpenNone
Resolvedphuedx
Resolvedphuedx
OpenNone
OpenNone
OpenNone
Resolvedphuedx
Resolvedphuedx
InvalidSGupta-WMF
ResolvedSfaci
Resolvedphuedx
Resolvedphuedx
ResolvedSfaci
ResolvedFrostly
ResolvedBUG REPORTphuedx
ResolvedSfaci
Resolvedphuedx
Resolvedphuedx
Resolvedcjming
Resolvedphuedx
ResolvedSpikephuedx
OpenNone
OpenNone
Resolvedphuedx
OpenNone
Resolvedphuedx
OpenKReid-WMF
Resolvedphuedx
OpenNone
Resolvedphuedx
OpenNone
DeclinedNone
OpenNone
Resolvedcjming
ResolvedKReid-WMF
ResolvedSfaci
OpenNone
OpenSfaci
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Resolvedphuedx
ResolvedSfaci
Resolvedphuedx

Event Timeline

just to be crystal about what is being deprecated/removed from EventLogging, are we agreeing the following will be targeted?

?

Assuming of course production code is migrated off these and corresponding/alternative methods are available in Test Kitchen.

just to be crystal about what is being deprecated/removed from EventLogging, are we agreeing the following will be targeted?

?

Assuming of course production code is migrated off these and corresponding/alternative methods are available in Test Kitchen.

I would say it's a good summary! Just a couple of comments:

/modules/ext.eventLogging/EventSubmitter.js - related ticket T375749: Migrate EventLogging to use DefaultEventSubmitter

My understanding in this case is that EventLogging should use DefaultEventSubmitter as a replacement for the EventSubmitter that is using right now but that code would stay in EventLogging. We mentioned that TestKitchen could be using EventLogging just as an "EventGate" client, right? That case I guess that EventLogging would still need DefaultEventSubmitter. But I guess that we would remove MetricsClient anyway (we could send events directly via a DefaultEventSubmitter object as Sam's patch is already doing). In fact we are already using DefaultEventSubmitter when sending events with experiments but instruments are still using just the current EventLogging.EventSubmmiter via MetricsClient (except the ones created via mw.tk.getInstrument, that ones are already using DefaultEventSubmitter)

mw.eventLog.submitInteraction

I also assume that we should migrate this same way we want to migrate mw.eventLog.newInstrument (both functions are very similar). I'm already working on filing a ticket to cover that work (a different one than the other about migrating mw.eventLog.newInstrument()

I would also add that we would remove the lib/metrics-platform folder from EventLogging (the folder we add as foreign resources as part of the JS client library)

Related to my question in https://phabricator.wikimedia.org/T415246#11548974 (and a couple of messages below) about what to do with usages of $this->metricsClientFactory->newMetricsClient( $context ), I have filed T416020: Deprecate and remove EventLogging.MetricsClientFactory service and some other related tickets to migrate the instruments that are using this service (now they are subtasks of the mentioned ticket).

The only pending one is related to GrowthExperiments extension. They are also using the EventLogging.MetricsClientFactory service. We have right now T407905: Update name in GrowthExperiments and ReaderExperiments extensions to work on some renaming and I have posted there a message to confirm what we are going to do regarding that (to use a separate ticket or the current one)