Error
- mwversion: 1.44.0-wmf.20
- reqId: 1204dedb-68e1-467a-9095-7d1f3e348a08
- Find reqId in Logstash
[{reqId}] {exception_url} CirrusSearch\Search\Rescore\InvalidRescoreProfileException: Unknown function score type growth_underlinked.[{reqId}] {exception_url} CirrusSearch\Search\Rescore\InvalidRescoreProfileException: Unknown function score type growth_underlinked.The proximal reason for the exception comes from GrowthExperiments\HomepageHooks::onCirrusSearchScoreBuilder which says:
// Not doing anything will result in a Cirrus error about a non-existent function type, // which seems like a reasonable way to handle the case of using underlinked weighting // on a wiki with no link recommendation task type.
The higher level explanation is that while growth experiments is installed to trwiki, link recommendations are not. I suppose the related problem is that the api's for trwiki claim to support srqiprofile=growth_underlinked, but when requesting the usage of it an exception is thrown. A better solution might be for growth_underlinked to not be listed as an allowable profile here, which would result in the api rejecting it as an invalid parameter in the normal ways. Looking into how plausible that is to implement.
Sounds like some of the CirrusSearch attributes should be set at runtime, rather than explicitly in extension.json?
Not sure if there's a useful hook they can use for CirrusSearch... Else doing it in something like extensionfunctions may be enough
The best answer might be if the CirrusSearchRescoreProfile attribute from GrowthExperiements extension.json was either conditional or had a callback that could be invoked to check if it is valid to use on this wiki. Then we could avoid registering it in CirrusSearch and it wouldn't be found by MediaWiki\Api\SearchApi::buildProfileApiParam. I took a quick look at ExtensionFunctions, it's not clear if it's reasonable (or possible) to change extension attributes from there. There is mention in the HISTORY file of a previous bug about changing configuration from there, and that ExtensionFunctions shouldn't be used for configuration changes. In a similar vein the only option I found for overriding attributes at runtime looks to be ExtensionRegistry::setAttributesForTest which clearly shouldn't be used here.
We have the CirrusSearchProfileService hook through which GrowthExperiments could conditionally register the rescore profile instead of always registering it via extension.json. This has the minor downside that we would then invoke GrowthExperiments code for every search query, when before it would only be invoked when attempting to use the profile.
We do have the concept of fallback profiles in cirrus and growth_underlinked is defined to use classic_noboostlinks in cases where the profile is requested against non-content namespaces. We could add a hook at that location that can declare the profile is not supported, in which case we would follow the normal fallback procedure. This would still invoke GrowthExperiments code, but I suspect it could be much thinner since it would only need to do the full check when the passed $profileName is the growth experiements specific profile.
Extensions are generally expected to declare their rescore settings via CirrusSearchProfileService instead of injecting something to the cirrus config. If the injection is not conditional the features this rescore require should not be conditional, would there be any issues dropping the if statement?
Perhaps it could always return, something like return new BoostedQueriesFunction( [ new MatchNone() ], [ .0 ] ); in the else statement?
But ideally it should not declare the growth_underlinked if it's not "buildable".
It is declaring it through a defined path, in particular extension.json has an "attributes" section, which is picked up by our ExtensionRegistryProfileRepository. The annoyance I suppose is that this is unconditional. I suppose the option of returning a function that does nothing seems viable, my expectation is that this usage is coming from someone looking at what the api claims is available and trying it out. I expect the intended UI that uses growth_underlinked wont be invoked on the wiki if link recommendations aren't deployed to that wiki.
Change #1130157 had a related patch set uploaded (by Ebernhardson; author: Ebernhardson):
[mediawiki/extensions/GrowthExperiments@master] Always return a rescore builder for growth_underlinked
Change #1130157 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Always return a function score builder for growth_underlinked
Our example query now works as expected without failing: https://tr.wikipedia.org/w/api.php?action=query&format=json&list=search&formatversion=2&srsearch=example&srqiprofile=growth_underlinked