Page MenuHomePhabricator

HistoryAction/FeedUtils triggers deprecated "Unexpected clearActionName after getActionName"
Closed, ResolvedPublicPRODUCTION ERROR

Description

Error
normalized_message
[{reqId}] {exception_url}   PHP Notice: Unexpected clearActionName after getActionName already called
exception.trace
from /srv/mediawiki/php-1.40.0-wmf.10/includes/context/RequestContext.php(311)
#0 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 /srv/mediawiki/php-1.40.0-wmf.10/includes/context/RequestContext.php(311): trigger_error(string)
#2 /srv/mediawiki/php-1.40.0-wmf.10/includes/context/RequestContext.php(176): RequestContext->clearActionName()
#3 /srv/mediawiki/php-1.40.0-wmf.10/includes/Feed/FeedUtils.php(187): RequestContext->setTitle(Title)
#4 /srv/mediawiki/php-1.40.0-wmf.10/includes/actions/HistoryAction.php(447): MediaWiki\Feed\FeedUtils::formatDiffRow2(Title, integer, integer, string, string)
#5 /srv/mediawiki/php-1.40.0-wmf.10/includes/actions/HistoryAction.php(413): HistoryAction->feedItem(stdClass, string)
#6 /srv/mediawiki/php-1.40.0-wmf.10/includes/actions/HistoryAction.php(200): HistoryAction->feed(string)
#7 /srv/mediawiki/php-1.40.0-wmf.10/includes/actions/FormlessAction.php(48): HistoryAction->onView()
#8 /srv/mediawiki/php-1.40.0-wmf.10/includes/MediaWiki.php(539): FormlessAction->show()
#9 /srv/mediawiki/php-1.40.0-wmf.10/includes/MediaWiki.php(317): MediaWiki->performAction(Article, Title)
#10 /srv/mediawiki/php-1.40.0-wmf.10/includes/MediaWiki.php(901): MediaWiki->performRequest()
#11 /srv/mediawiki/php-1.40.0-wmf.10/includes/MediaWiki.php(559): MediaWiki->main()
#12 /srv/mediawiki/php-1.40.0-wmf.10/index.php(50): MediaWiki->run()
#13 /srv/mediawiki/php-1.40.0-wmf.10/index.php(46): wfIndexMain()
#14 /srv/mediawiki/w/index.php(3): require(string)
#15 {main}
Impact

~70 of these since deploying T320515: 1.40.0-wmf.10 deployment blockers to group0 a few minutes ago.

Notes

I'm guessing this is T314008: Promote dirty RequestContext::clearActionName to runtime warning, although most of the errors I'm seeing are from feeds specifically.

Tentatively treating as a blocker but not yet rolling back from group0, since it doesn't seem like the feeds themselves are broken.

Event Timeline

brennen triaged this task as Unbreak Now! priority.Nov 15 2022, 7:24 PM
brennen created this task.
Umherirrender subscribed.

The first call is from MediaWiki\Extension\InputBox\InputBoxHooks->onMediaWikiPerformAction, the FeedUtil is cloning the main request context and that clones also the action field. Just using a DerivativeContext seems better.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/InputBox/+/831153 is not a issue, but also included in this train, it fails before also with the patch from T314008

Change 857041 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] Feed: Use DerivativeContext and not clone main RequestContext

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

Perhaps we should forbid cloning of RequestContext to avoid similar issues in the future.

Change 856582 had a related patch set uploaded (by Tim Starling; author: Umherirrender):

[mediawiki/core@wmf/1.40.0-wmf.10] Feed: Use DerivativeContext and not clone main RequestContext

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

Change 857041 merged by jenkins-bot:

[mediawiki/core@master] Feed: Use DerivativeContext and not clone main RequestContext

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

Perhaps we should forbid cloning of RequestContext to avoid similar issues in the future.

There is no other code like that

It seems only a bad idea if the main get cloned, but the logging would also trigger for non-main RequestContext, but it is unlikly the action is reset there by a setter. Not sure if an exception on clone would help or better to make all RequestContext objects non-clonable.

Change 856582 merged by jenkins-bot:

[mediawiki/core@wmf/1.40.0-wmf.10] Feed: Use DerivativeContext and not clone main RequestContext

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

Mentioned in SAL (#wikimedia-operations) [2022-11-15T23:19:24Z] <brennen@deploy1002> Started scap: Backport for [[gerrit:856582|Feed: Use DerivativeContext and not clone main RequestContext (T323153)]]

Mentioned in SAL (#wikimedia-operations) [2022-11-15T23:19:50Z] <brennen@deploy1002> brennen and tstarling: Backport for [[gerrit:856582|Feed: Use DerivativeContext and not clone main RequestContext (T323153)]] synced to the testservers: mwdebug1002.eqiad.wmnet, mwdebug2002.codfw.wmnet, mwdebug2001.codfw.wmnet, mwdebug1001.eqiad.wmnet

Mentioned in SAL (#wikimedia-operations) [2022-11-15T23:25:53Z] <brennen@deploy1002> Finished scap: Backport for [[gerrit:856582|Feed: Use DerivativeContext and not clone main RequestContext (T323153)]] (duration: 06m 26s)

Perhaps we should forbid cloning of RequestContext to avoid similar issues in the future.

There is no other code like that

It seems only a bad idea if the main get cloned, but the logging would also trigger for non-main RequestContext, but it is unlikly the action is reset there by a setter. Not sure if an exception on clone would help or better to make all RequestContext objects non-clonable.

Agreed, the above has close to no results. 1 match in a third-party repo (femwiki), and 2 matches in a unit test. RequestContext is effectively always the main one given that all its methods default to global state. We have DerivedContext for safely creating overriddes whilest continuing to re-use the same references from the parent context for non-overridden fields. I would support throwing fatal from __clone() with a message that DerivedContext should be used instead. That would also help new developers that might try this. While there is virtually no code that does this today, it seems likely to regress unless regularly reminded through code review, which is one more thing we can automate and ensure is discovered and passed on without relying on specific people to spread the word.

Krinkle renamed this task from PHP Notice: Unexpected clearActionName after getActionName already called to HistoryAction/FeedUtils triggers deprecated "Unexpected clearActionName after getActionName".Nov 17 2022, 9:10 AM