Hi @ssingh!
Just a friendly reminder of what we mentioned about running this test with higher traffic. The current experiment ended after being running with 1.6% of the English Wikipedia traffic as the final step, and we would like to run it again with more traffic (up to 5-6%, increasing by 1% every 2/3 days). Would you be ok with that plan?

@Jdforrester-WMF We are pretty close to start the removal of MetricsPlatform extension and we think we should remove any occurrence of that extension to avoid problems in the future. Regarding this case, based on your words about that no rapid updating is needed here. Would it be ok for you if we just rename MetricsPlatform with TestKitchen once we start removing MetricsPlatform? like an additional step for T416865: Remove MetricsPlatform extension, as the ones we will have to address regarding the integration/config repository

This experiment will be renamed via T407904: Update name in EventLogging Extension and WikimediaEvents Extension along with the other instruments that reside in WikimediaEvents.
Just in case, I have added, to the mentioned ticket, the change about the related configuration because it resides in wikimedia-config repository and it's something usual for experiments that live in WikimediaEvents

My first guess is that the bug is caused when updating the machine-readable name (also known as slug in the codebase) because we use it to get an instance of that instrument/experiment as a reference to check, later during validation, if some fields have been modified (not everything is allowed). At that moment, because the machine-readable name is a new one, we get nothing and some validation fail because we are expecting to have something to get from what we consider the current data

The last patch we deployed is not still showing the quick link to the superset dashboard when a logged-out user is viewing an experiment via the public Read View. We need to investigate further how to do it

Last patch makes registered-experiments also public so public Read view can show when the experiment is registered and also the quick link to its superset dashboard

Hi @Sfaci. Most of the team is out this week for the SRE offsite so we will follow up on your question and the ask for observation during the week of Feb 2. Thanks.

Now that we are considering T415579: Migrate JS and PHP client libraries to TestKitchen extension and T415858: [Epic] Bring Test Kitchen Kotlin SDK to functional parity with JS + PHP as a separate work this task doesn't make sense. In the case of JS and PHP we are going to migrate client libraries to be part of TestKitchen extension and in the case of Java we are already working on refactoring and updating that client library with Kotlin.

Closing this task as invalid because the renaming mentioned above cannot be done without having deprecated and removed first the related service. That will be done in T416020: Deprecate and remove EventLogging.MetricsClientFactory service and we have filed T415650: Migrate ReportIncident PHP instrument to use Test Kitchen SDK to address this work accordingly when appropriate

Closing this task as invalid because the renaming mentioned above cannot be done without having deprecated and removed first the related service. That will be done in T416020: Deprecate and remove EventLogging.MetricsClientFactory service and we have filed T415654: Migrate CheckUser PHP instrument to use Test Kitchen SDK to address this work accordingly when appropriate

I started already with this by filing a couple of tasks to migrate specific instruments that are using that way (T415650: Migrate ReportIncident PHP instrument to use Test Kitchen SDK and T415654: Migrate CheckUser PHP instrument to use Test Kitchen SDK, for example) so I'll create the pending ones and also the specific task to deprecate that EventLogging.MetricsClientFactory service. And I will link all of them accordingly

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).

@cjming GrowthExperiment extension is also using EventLogging.MetricsClientFactory service which is something we would like to deprecate and remove as part of T408059: [GOAL] Tidy up EventLogging. I have just created a ticket to deprecate and remove that service at some point (T416020: Deprecate and remove EventLogging.MetricsClientFactory service).