Editing session issue (TitleBlacklist related?) on *.wikipedia.org for Kvardek du
Open, Needs TriagePublic
Actions

Assigned To

None

Authored By

	Dereckson
	Dec 25 2016, 6:50 PM

Description

We have an issue with a contributor from the French Wikimedia, Kvardek du.

When they try to save an article on fr.wikipedia.org or other *.wikipedia.org, a session_fail_preview error message (es.). Behavior persists after cookie clearing. Behavior doesn't persist in private browser mode, so it looks browser-session related.

A debug request with log enabled has been done on mwdebug1002 @ 2016-12-25T18:13:43 - 18:13:44. It's available on logstash. No error is logged when the user tries to edit, but when they visited en.wikipedia just afterwards, two kind of error type occur:

a session error: when some JS code wanted a JSON response but got a PHP Notice: A session had already been started ignoring session_start() (possibily because of the next?)
a TitleBlacklist error: PHP Warning: Compilation failed: missing ) at offset 63 @ /srv/mediawiki/php-1.29.0-wmf.6/extensions/TitleBlacklist/TitleBlacklist.list.php line 43

In VE mode, there is no issue.

On a side note, on Flow, it's possible to write topic, but when trying to delete them a ''Invalid CSRF token'' message is received, then the topic is deleted.

Finally, could be related to T151770 as this contributor also expected this issue on Firefox.

Details

	Subject	Repo	Branch	Lines +/-
	Validate all pages which are blacklist sources	mediawiki/extensions/TitleBlacklist	master	+30 -11
	Use Title_blacklist as a local page on meta	operations/mediawiki-config	master	+15 -6

Customize query in gerrit

Related Objects

Mentioned In: T158270: PHP warnings should be logged via Monolog (with a stack trace), not HHVM
Mentioned Here: T45086: Capture PHP warnings with stacktraces in MediaWiki and save to logstash
T75619: Debug: Log group 'error' for PHP errors should abide wfSuppressWarnings
T136849: normalized_message is a JSON dump of the whole event for exceptions in beta logstash
T151770: Frequent loss of session data in Firefox (since around 2016-11-28)

Event Timeline

Dereckson created this task.Dec 25 2016, 6:50 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 25 2016, 6:50 PM

Dereckson updated the task description. (Show Details)Dec 25 2016, 7:02 PM

The errors in readable format:

ErrorException: PHP Notice: A session had already been started - ignoring session_start()
fr.wikipedia.org/w/api.php
  #0 null(null): MWExceptionHandler::handleError(integer, string, string, integer, array, array)
  #1 null(null): session_start()
  #2 /srv/mediawiki/php-1.29.0-wmf.6/vendor/mediawiki/at-ease/src/Functions.php(72): call_user_func_array(string, array)
  #3 /srv/mediawiki/php-1.29.0-wmf.6/includes/Setup.php(790): MediaWiki\quietCall(string)
  #4 /srv/mediawiki/php-1.29.0-wmf.6/includes/WebStart.php(137): include(string)
  #5 /srv/mediawiki/php-1.29.0-wmf.6/api.php(38): include(string)
  #6 /srv/mediawiki/w/api.php(3): include(string)

ErrorException: PHP Warning: Compilation failed: missing ) at offset 63
fr.wikipedia.org/w/api.php /srv/mediawiki/php-1.29.0-wmf.6/extensions/TitleBlacklist/TitleBlacklist.list.php line 403
  #0 /srv/mediawiki/php-1.29.0-wmf.6/extensions/TitleBlacklist/TitleBlacklist.list.php(403): MWExceptionHandler::handleError(integer, string, string, integer, array, array)
  #1 /srv/mediawiki/php-1.29.0-wmf.6/extensions/TitleBlacklist/TitleBlacklist.list.php(188): TitleBlacklistEntry->matches(string, string)
  #2 /srv/mediawiki/php-1.29.0-wmf.6/extensions/TitleBlacklist/TitleBlacklist.list.php(153): TitleBlacklist->isBlacklisted(Title, string)
  #3 /srv/mediawiki/php-1.29.0-wmf.6/extensions/TitleBlacklist/TitleBlacklist.hooks.php(53): TitleBlacklist->userCannot(Title, User, string)
  #4 /srv/mediawiki/php-1.29.0-wmf.6/includes/Hooks.php(195): TitleBlacklistHooks::userCan(Title, User, string, string)
  #5 /srv/mediawiki/php-1.29.0-wmf.6/includes/Title.php(2093): Hooks::run(string, array)
  #6 /srv/mediawiki/php-1.29.0-wmf.6/includes/Title.php(2524): Title->checkPermissionHooks(string, User, array, string, boolean)
  #7 /srv/mediawiki/php-1.29.0-wmf.6/includes/Title.php(1950): Title->getUserPermissionsErrorsInternal(string, User, string)
  #8 /srv/mediawiki/php-1.29.0-wmf.6/includes/api/ApiBase.php(1838): Title->getUserPermissionsErrors(string, User)
  #9 /srv/mediawiki/php-1.29.0-wmf.6/includes/api/ApiEditPage.php(125): ApiBase->checkTitleUserPermissions(Title, string)
  #10 /srv/mediawiki/php-1.29.0-wmf.6/includes/api/ApiMain.php(1532): ApiEditPage->execute()
  #11 /srv/mediawiki/php-1.29.0-wmf.6/includes/api/ApiMain.php(510): ApiMain->executeAction()
  #12 /srv/mediawiki/php-1.29.0-wmf.6/extensions/VisualEditor/ApiVisualEditorEdit.php(56): ApiMain->execute()
  #13 /srv/mediawiki/php-1.29.0-wmf.6/extensions/VisualEditor/ApiVisualEditorEdit.php(285): ApiVisualEditorEdit->saveWikitext(Title, string, array)
  #14 /srv/mediawiki/php-1.29.0-wmf.6/includes/api/ApiMain.php(1532): ApiVisualEditorEdit->execute()
  #15 /srv/mediawiki/php-1.29.0-wmf.6/includes/api/ApiMain.php(541): ApiMain->executeAction()
  #16 /srv/mediawiki/php-1.29.0-wmf.6/includes/api/ApiMain.php(512): ApiMain->executeActionWithErrorHandling()
  #17 /srv/mediawiki/php-1.29.0-wmf.6/api.php(83): ApiMain->execute()
  #18 /srv/mediawiki/w/api.php(3): include(string)

There are multiple TitleBlacklist issues here, which are completely unrelated to the session loss problem (that's probably T151770 or in any case pointless to debug as long as that bug generates session errors left and right):

TitleBlacklist should prevent the user from saving an invalid regex (TitleBlacklist::validateBlacklist does that, but only for MediaWiki:Titleblacklist, not the meta page)
TitleBlacklist should log regex errors intelligently (include enough information to easily identify which regex has errors)
the warning is thrown in the middle of a wfSuppressWarnings block, which I would expect to prevent such errors from being logged in the exception channel and/or with severity level ERROR. (MWExceptionHandler puts suppressed: true in the error data but that's not particularly useful as it ends up as a JSON string; that's T136849, sort of.) @bd808 any thoughts about shoving such errors into a separate suppressed-error channel?

The other warning is due to something setting up a PHP session before Setup.php could do it. Presumably SessionManager::getSessionFromInfo when noticing something is wrong with the current session and resetting the ID, in which case it's a consequence of the session loss bug but not a bug in itself.

In T154112#2908000, @Tgr wrote:

@bd808 any thoughts about shoving such errors into a separate suppressed-error channel?

Honoring the suppression flag was T75619: Debug: Log group 'error' for PHP errors should abide wfSuppressWarnings. In T45086: Capture PHP warnings with stacktraces in MediaWiki and save to logstash when we logged all of the suppressed errors we had too much log volume to handle. It was something like 1G per minute to fluorine as I recall. It probably wouldn't hurt anything to route the messages to a channel that is normally ignored on Wikimedia wikis. Anyone who runs their wiki with all log channels enabled is likely used to seeing tons of useless logging.

Change 330326 had a related patch set uploaded (by Gergő Tisza):
Validate all pages which are blacklist sources

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

gerritbot added a project: Patch-For-Review.Jan 3 2017, 11:13 PM

Change 330328 had a related patch set uploaded (by Gergő Tisza):
Use Title_blacklist as a local page on meta

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

Liuxinyu970226 subscribed.Jan 29 2017, 11:54 AM

Tgr mentioned this in T158270: PHP warnings should be logged via Monolog (with a stack trace), not HHVM.Feb 20 2017, 6:29 PM

I am wishing for meta's global title blacklist to be regex-checked. It has been indicated to me that the gerrit here may be part of the solution. Are we able to see whether that is the case, and if it is, are we able to look to implement this fix. Thanks.

Change 330328 abandoned by Jforrester:
Use Title_blacklist as a local page on meta

Reason:
Dependency still isn't merged after two years.