Page MenuHomePhabricator

Wikimedia\Assert\InvariantException: Invariant failed: $campaignName is not null
Closed, ResolvedPublicPRODUCTION ERROR

Description

Error
labels.normalized_message
[{reqId}] {exception_url}   Wikimedia\Assert\InvariantException: Invariant failed: $campaignName is not null
FrameLocationCall
from/srv/mediawiki/php-1.44.0-wmf.13/vendor/wikimedia/assert/src/Assert.php(231)
#0/srv/mediawiki/php-1.44.0-wmf.13/extensions/GrowthExperiments/includes/CampaignBenefitsBlock.php(57)Wikimedia\Assert\Assert::invariant(bool, string)
#1/srv/mediawiki/php-1.44.0-wmf.13/extensions/GrowthExperiments/includes/VariantHooks.php(297)GrowthExperiments\CampaignBenefitsBlock->getHtml()
#2/srv/mediawiki/php-1.44.0-wmf.13/includes/HookContainer/HookContainer.php(155)GrowthExperiments\VariantHooks->onSpecialCreateAccountBenefits(null, array, array)
#3/srv/mediawiki/php-1.44.0-wmf.13/includes/HookContainer/HookRunner.php(3695)MediaWiki\HookContainer\HookContainer->run(string, array)
#4/srv/mediawiki/php-1.44.0-wmf.13/includes/specialpage/LoginSignupSpecialPage.php(664)MediaWiki\HookContainer\HookRunner->onSpecialCreateAccountBenefits(null, array, array)
#5/srv/mediawiki/php-1.44.0-wmf.13/includes/specialpage/LoginSignupSpecialPage.php(625)MediaWiki\SpecialPage\LoginSignupSpecialPage->getPageHtml(string)
#6/srv/mediawiki/php-1.44.0-wmf.13/includes/specialpage/LoginSignupSpecialPage.php(407)MediaWiki\SpecialPage\LoginSignupSpecialPage->mainLoginForm(array, string, string)
#7/srv/mediawiki/php-1.44.0-wmf.13/includes/specialpage/SpecialPage.php(729)MediaWiki\SpecialPage\LoginSignupSpecialPage->execute(null)
#8/srv/mediawiki/php-1.44.0-wmf.13/includes/specialpage/SpecialPageFactory.php(1735)MediaWiki\SpecialPage\SpecialPage->run(null)
#9/srv/mediawiki/php-1.44.0-wmf.13/includes/actions/ActionEntryPoint.php(503)MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, MediaWiki\Context\RequestContext)
#10/srv/mediawiki/php-1.44.0-wmf.13/includes/actions/ActionEntryPoint.php(145)MediaWiki\Actions\ActionEntryPoint->performRequest()
#11/srv/mediawiki/php-1.44.0-wmf.13/includes/MediaWikiEntryPoint.php(202)MediaWiki\Actions\ActionEntryPoint->execute()
#12/srv/mediawiki/php-1.44.0-wmf.13/index.php(58)MediaWiki\MediaWikiEntryPoint->run()
#13/srv/mediawiki/w/index.php(3)require(string)
#14{main}
Impact
Notes

Details

Request URL
https://es.wikipedia.org/wiki/Especial:Crear_una_cuenta?campaign=*
Related Changes in Gerrit:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

This is happening on my staff account, but not in an anonymous version. This seems to be because my growthexperiments-campaign preference is set to growth-glam-2022, which does not exist anymore. Setting the user preference to an arbitrary string on another wiki causes the breakage as well. Something is using growthexperiments-campaign instead of the ?campaign parameter.

It seems VariantHooks::getCampaign() is giving preference to the user preference, as opposed to the URL parameter. I guess that is reasonable in most places where a campaign is needed, but it causes the issue here. Switching the priority would fix this issue, and I don't think it should cause any new ones (someone could technically go to Special:Homepage and enable extra topics via the campaign URL parameter, but that is not necessarily a bad thing).

@Sgs @Michael Any thoughts on this, please?

I haven't looked into the code yet, but both a user-preference as well as a url-parameter are user-editable. That means that neither must be allowed to cause a production error, regardless of the value.

As for what should have preference: I agree that probably the URL-parameter should have preference, because in my mind the scenario "I'm usually enrolled in one campaign. But then in a project or editathon, I click a link of a different campaign - which do I see?" would be common to cause that conflict, and in that case I would expect to see the topics from the URL parameters.

That being said, didn't we plan to remove all the campaigns functionality from GrowthExperiments, or have I been imagining things? But I can't seem to find a task for this while skimming the board.

I haven't looked into the code yet, but both a user-preference as well as a url-parameter are user-editable. That means that neither must be allowed to cause a production error, regardless of the value.

Agreed. As far as I can see, we do check for an allowlist before considering the value, but the mismatch causes all the trouble here.

As for what should have preference: I agree that probably the URL-parameter should have preference, because in my mind the scenario "I'm usually enrolled in one campaign. But then in a project or editathon, I click a link of a different campaign - which do I see?" would be common to cause that conflict, and in that case I would expect to see the topics from the URL parameters.

Thanks for the 2o. FWIW, visiting the campaign once would be probably confusing, as you'd lose access to the extra features whenever you navigate away. Seems more useful for debugging/QA/power users. The campaign is also intended to be set on registration (and then only accessed).

That being said, didn't we plan to remove all the campaigns functionality from GrowthExperiments, or have I been imagining things? But I can't seem to find a task for this while skimming the board.

Only campaign topics related code (T380483). This error is related to the sign up page campaigns (that result in a non-standard sign up page), which we want to keep indefinitely. For the record, there is also MediaWiki-extensions-Campaigns, which is the owner of the ?campaign query parameter that we piggyback on (that extension should be kept as well, of course).

Change #1117524 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/GrowthExperiments@master] Fix signup campaign error by prioritizing URL params over user prefs

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

Change #1117524 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Fix signup campaign error by prioritizing URL params over user prefs

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

Etonkovidova removed Cyndymediawiksim as the assignee of this task.

The errors are not present - logstash link for last 30 days