Page MenuHomePhabricator

InvalidArgumentException from SpecialBlock.php: "$comment can not be null"
Closed, ResolvedPublicPRODUCTION ERROR

Description

[XMg2-wpAICIAAE4Q9OwAAABN] 2019-04-30 11:52:32: Fatal exception of type "InvalidArgumentException" on zhwiki

Event Timeline

Xiplus renamed this task from InvalidArgumentException when blocing user on zhwiki to InvalidArgumentException when blocking user on zhwiki.Apr 30 2019, 11:55 AM
message
[XMg2-wpAICIAAE4Q9OwAAABN] /wiki/Special:%E5%B0%81%E7%A6%81/2001:B011:E005:0:0:0:0:0/48   InvalidArgumentException from line 591 of /srv/mediawiki/php-1.34.0-wmf.1/includes/CommentStore.php: $comment can not be null
trace
#0 /srv/mediawiki/php-1.34.0-wmf.1/includes/Block.php(708): CommentStore->insert(Wikimedia\Rdbms\DatabaseMysqli, string, NULL)
#1 /srv/mediawiki/php-1.34.0-wmf.1/includes/Block.php(561): Block->getDatabaseArray(Wikimedia\Rdbms\DatabaseMysqli)
#2 /srv/mediawiki/php-1.34.0-wmf.1/includes/specials/SpecialBlock.php(909): Block->insert()
#3 /srv/mediawiki/php-1.34.0-wmf.1/includes/specials/SpecialBlock.php(1225): SpecialBlock::processForm(array, RequestContext)
#4 /srv/mediawiki/php-1.34.0-wmf.1/includes/htmlform/HTMLForm.php(675): SpecialBlock->onSubmit(array, OOUIHTMLForm)
#5 /srv/mediawiki/php-1.34.0-wmf.1/includes/htmlform/HTMLForm.php(567): HTMLForm->trySubmit()
#6 /srv/mediawiki/php-1.34.0-wmf.1/includes/htmlform/HTMLForm.php(582): HTMLForm->tryAuthorizedSubmit()
#7 /srv/mediawiki/php-1.34.0-wmf.1/includes/specialpage/FormSpecialPage.php(184): HTMLForm->show()
#8 /srv/mediawiki/php-1.34.0-wmf.1/includes/specialpage/SpecialPage.php(569): FormSpecialPage->execute(string)
#9 /srv/mediawiki/php-1.34.0-wmf.1/includes/specialpage/SpecialPageFactory.php(578): SpecialPage->run(string)
#10 /srv/mediawiki/php-1.34.0-wmf.1/includes/MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#11 /srv/mediawiki/php-1.34.0-wmf.1/includes/MediaWiki.php(865): MediaWiki->performRequest()
#12 /srv/mediawiki/php-1.34.0-wmf.1/includes/MediaWiki.php(515): MediaWiki->main()
#13 /srv/mediawiki/php-1.34.0-wmf.1/index.php(42): MediaWiki->run()
#14 /srv/mediawiki/w/index.php(3): require(string)
#15 {main}
Daimona renamed this task from InvalidArgumentException when blocking user on zhwiki to InvalidArgumentException when blocking user: $comment can not be null.Apr 30 2019, 12:11 PM

Which wiki has occur this exception?

Seen 7 times in the last week, 4 of which were on zhwiki today at short breaks (probably the user re-tried to submit the form).

Seen 7 times in the last week, 4 of which were on zhwiki today at short breaks (probably the user re-tried to submit the form).

Yes. I resubmitted the form 3 times.

I remember that the reason part of form was broken in appearance (Maybe something was not loaded because of my network). But I can still select a block reason.

I can reproduce this bug on Beta Cluster by deleting the html of reason part of the form.

I suggest to display error message like MediaWiki:Edit form incomplete instead of exception.

Krinkle renamed this task from InvalidArgumentException when blocking user: $comment can not be null to InvalidArgumentException from SpecialBlock.php: "$comment can not be null".May 30 2019, 12:12 AM
Krinkle added a subscriber: Krinkle.

Still seen in Logstash. Affects both PHP 7.2 and HHVM requests. Only seen from Special:Block requests. (And currently only from zh.wikipedia.org, which may or may not be a coincidence).

Logstash query: https://logstash.wikimedia.org/goto/a39a24530f37d7ce447082121ad1f771.

This exception can be reproduced by removing this node (and it's children) from the DOM:

<select tabindex="0" aria-disabled="false" name="wpReason" class="oo-ui-inputWidget-input oo-ui-indicator-down"></select>

and then saving the form.

Niharika triaged this task as Medium priority.May 30 2019, 4:31 PM

We could display an error message, but if we do that then we should try to be consistent across all forms, ie always be prepared to handle submission of forms that haven't loaded properly.

It would be really helpful to understand why this form keeps failing to load, and try to fix that root cause. The fact that it has been happening since around mid-April, and only on zhwiki, seems to suggest that there is some cause: https://logstash.wikimedia.org/goto/c9eb16af8a6f908e8f2d060e7f587954

Incidentally, this first occurred a couple of days before partial blocks was enabled (T220434). Perhaps some message in the reason field was re-translated around this time?

@A2093064 Can you remember how the form was broken in appearance (or do you have a screenshot)?

@Tchanders I refreshed the page several times then got this screenshot.

block.png (3×1 px, 371 KB)

We could display an error message, but if we do that then we should try to be consistent across all forms, ie always be prepared to handle submission of forms that haven't loaded properly.

I think we should set the default reason (somewhere?) to an empty string. An empty string seems to be completely valid and doesn't throw an error.

@A2093064 Thanks for the screenshot.

I'm struggling to reproduce this on https://zh.wikipedia.org/wiki/Special:封禁?uselang=zh-TW Which browser version/OS are you using, and do you have any gadgets or browser-plugins installed?

@Tchanders Yes. It's very difficult to reproduce it.
My environment is Google Chrome Version 74.0.3729.169 (Official Build) (64-bit) on Windows 10 Version 10.0.17134 Build 17134.
I have enabled many Chrome extensions, sitewide gadgets, and imported so many scripts in common.js. But scripts will affect block interface only are MediaWiki:Group-sysop.js (Line 31-69) and m:User:Xiplus/js/block-time-convert.js.

This exception can be reproduced by removing this node (and it's children) from the DOM:

<select tabindex="0" aria-disabled="false" name="wpReason" class="oo-ui-inputWidget-input oo-ui-indicator-down"></select>

I don't know about the Block form specifically, but more generally for request parameters through a user submitted I expect all fields to have an effective default that is identical to the form being submitted as initially presented. For most fields that would be the empty string.

Foreign input from request parameters can never be assumed to be valid in terms of value or type, client-side validation should therefore generally be treated as an enhancement. In this case it seems a value from $request->getVal() would appear to have made its way all the way to CommentStore->insert($db, …, $value). I would assume that either along the way this is validated, or the original retrieval to defer it to the WebRequest class by demanding a specific type, e.g. by using getText(), getCheck(), getInt(), or getIntOrNull, where getVal is essentially "getTextOrNull".

Aside from code that interacts with WebRequest directly, I believe the HTMLForm also has a similar feature, but declarative instead of imperative. Where you specify a default key for the form field. I haven't tested this lately, though, so maybe that's broken or not as I remember!

@A2093064 The broken appearance of the page seems to be down to the MediaWiki:Group-sysop.js script.

The line:

mw.loader.using('jquery.colorUtil').then(function() {

should be changed to:

mw.loader.using(['jquery.colorUtil', 'mediawiki.special.block']).then(function() {

to ensure that the Special:Block JavaScript runs before the script.

Whether this is definitely the cause of the error remains to be seen though - in my local tests, breaking the form with the script didn't cause the same error, but there may be some differences.

Change 517147 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Ensure HTMLSelectAndOtherField has correct type of default value

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

to ensure that the Special:Block JavaScript runs before the script.

Fixed this script.

Change 517147 merged by jenkins-bot:
[mediawiki/core@master] Fix some issues with HTMLSelectAndOtherField default and validation

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

Change 517474 had a related patch set uploaded (by Krinkle; owner: Tchanders):
[mediawiki/core@wmf/1.34.0-wmf.8] Fix some issues with HTMLSelectAndOtherField default and validation

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

Change 517474 merged by jenkins-bot:
[mediawiki/core@wmf/1.34.0-wmf.8] Fix some issues with HTMLSelectAndOtherField default and validation

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

Mentioned in SAL (#wikimedia-operations) [2019-06-18T22:20:25Z] <krinkle@deploy1001> Synchronized php-1.34.0-wmf.8/includes/htmlform/fields/HTMLSelectAndOtherField.php: rMW90b513d96e36 / T222170 (duration: 00m 57s)

Krinkle assigned this task to Tchanders.

Yep, seems so.

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:07 PM