Page MenuHomePhabricator

Create PHP equivalent of mw.testKitchen.getInstrument()
Closed, ResolvedPublic3 Estimated Story Points

Description

Background

The Safety and Security team created a custom schema to capture hCaptcha risk scores for various activities and have submitted a patch to introduce a new stream that uses the schema. Currently, they can't create an instrument in Test Kitchen UI and/or use the Test Kitchen PHP SDK to implement the instrument because the PHP SDK is lagging behind the JS SDK slightly. Concretely, the PHP SDK needs the equivalent of mw.testKitchen.getInstrument().

Suggested API
my-awesome-instrument.php
/** @var \MediaWiki\Extension\MetricsPlatform\XLab\InstrumentManager $instrumentManager */
$instrumentManager = $services->getService( 'MetricsPlatform.XLab.InsturmentManager' )
    ->getInstrument( 'my-awesome-instrument' );
Instrument.php
namespace MediaWiki\Extension\MetricsPlatform\XLab;

interface InstrumentManager {
    public function getInstrument( string $instrumentName ): Instrument;
}

interface Instrument {
    public function send( string $action, array $interactionData = [] ): void;
}
Acceptance Criteria

Verify with a production instrument and ready to deploy to production.

Related Objects

Event Timeline

I think we should also address here for the PHP client library what we implemented in T398480: [Epic] Update instruments configuration for xLab for the JS one. That Epic talks in general but, regarding the client libraries, nothing was done for the PHP client library. I would say we should do the same we did for JS (https://gitlab.wikimedia.org/repos/data-engineering/metrics-platform/-/merge_requests/100)

JVanderhoop-WMF moved this task from Incoming to READY TO GROOM on the Test Kitchen board.
JVanderhoop-WMF subscribed.

How many instruments are written client-side vs server-side? I'll at least prioritize as lower, especially as we move towards the Vision™

How many instruments are written client-side vs server-side? I'll at least prioritize as lower, especially as we move towards the Vision™

I would say that there are more client-side instruments (some details in https://wikitech.wikimedia.org/wiki/Test_Kitchen/Instrument_list) but it's also true that the JS client library was always the one with more features and the one that receives first all the new features. PHP client library was and is always behind JS regarding features. Not sure but that could be a reason to incline numbers towards client side instrumentation. Or at least I would say it should be something to consider. In fact this ticket is even a good example of that.

KReid-WMF renamed this task from Create PHP equivalent of mw.xLab.getInstrument() to Create PHP equivalent of mw.testKitchen.getInstrument().Jan 13 2026, 4:46 PM
KReid-WMF updated the task description. (Show Details)

@Sfaci shared:

Why not something like $this->instrumentManager->getInstrument() like we do for experiments? We already have something like $this->experimentManager->getExperiment()
but there is some magic we do in ServiceWiring.php to simplify the way those components are instantiated and used. That way developers can use it more easily

As @phuedx has mentioned in the doc about the renaming, the instrument that resides in the Wikilambda extension could be a good candidate for the implementation we are going to work on here. That instrument was implemented even before than MetricsPlatform existed so, in reality as Sam mentioned, it shouldn't be part of the renaming itself but part of this task as a way to deprecate the older way of implementing/interacting with instrument and send related events

Change #1237339 had a related patch set uploaded (by Santiago Faci; author: Santiago Faci):

[mediawiki/extensions/TestKitchen@master] PHP SDK: Add InstrumentManager#getInstrument()

https://gerrit.wikimedia.org/r/1237339

Change #1237339 merged by jenkins-bot:

[mediawiki/extensions/TestKitchen@master] PHP SDK: Add InstrumentManager#getInstrument()

https://gerrit.wikimedia.org/r/1237339