Page MenuHomePhabricator

SearchHandler: PHP Warning: array_merge(): Argument #2 is not an array
Closed, ResolvedPublic3 Estimated Story PointsPRODUCTION ERROR

Description

Error
normalized_message
[{reqId}] {exception_url}   PHP Warning: array_merge(): Argument #2 is not an array
exception.trace
from /srv/mediawiki/php-1.38.0-wmf.9/includes/Rest/Handler/SearchHandler.php(335)
#0 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 [internal function]: array_merge(array, NULL, NULL)
#2 /srv/mediawiki/php-1.38.0-wmf.9/includes/Rest/Handler/SearchHandler.php(335): array_map(string, array, array, array)
#3 /srv/mediawiki/php-1.38.0-wmf.9/includes/Rest/Router.php(414): MediaWiki\Rest\Handler\SearchHandler->execute()
#4 /srv/mediawiki/php-1.38.0-wmf.9/includes/Rest/Router.php(338): MediaWiki\Rest\Router->executeHandler(MediaWiki\Rest\Handler\SearchHandler)
#5 /srv/mediawiki/php-1.38.0-wmf.9/includes/Rest/EntryPoint.php(167): MediaWiki\Rest\Router->execute(MediaWiki\Rest\RequestFromGlobals)
#6 /srv/mediawiki/php-1.38.0-wmf.9/includes/Rest/EntryPoint.php(132): MediaWiki\Rest\EntryPoint->execute()
#7 /srv/mediawiki/php-1.38.0-wmf.9/rest.php(31): MediaWiki\Rest\EntryPoint::main()
#8 /srv/mediawiki/w/rest.php(3): require(string)
#9 {main}
Impact
Notes

Noticed a handful of these in 1.38.0-wmf.9 while triaging logs for wmf.12.

Details

Request URL
https://en.wikipedia.org/w/rest.php/v1/search/page?q=*&limit=*&maxlag=*

Event Timeline

@sdkim , this looks to be a REST API issue. Can you/your team confirm? My team says nobody on our team has seen this code before

Sure thing @MPhamWMF do you know the severity of this issue? I'll prioritize accordingly

Thanks @sdkim . I don't know the severity on this issue because my team doesn't seem to know what's going on. But it doesn't seem like it's breaking anything right now as far as i know

sdkim set the point value for this task to 3.Dec 16 2021, 5:06 PM
sdkim moved this task from Incoming to Must do now on the API Platform board.

Initial triage suggests that affected requests are not returning results when they should be. So while not a massively breaking change on a wiki-wide level, there does appear to be a user impact.

Specifically, the file being searched for in the request from the description does exist, even though the search handler in this case returns no pages:
https://en.wikipedia.org/wiki/File:Russian_balls_12-13.jpg
vs.
https://en.wikipedia.org/w/rest.php/v1/search/page?q=File%3ARussian+balls+12-13.jpg&limit=1&maxlag=1

A bit of logstash digging shows this to affect only searches for pages in the File namespace, which at least limits the impact.

Executed this via eval.php (this is just the relevant parts of SearchHandler.php pulled out and adjusted so it will execute):

https://gist.github.com/bpirkle/19e5bed7e33daccfcba790a0ec8a26ae

Here it is on one line if someone else wants to do the same:

https://gist.github.com/bpirkle/ef8fe4c257a3ee4752a621bd374b9a21

Output:

Array
(
    [0] => Array
        (
            [id] => 0
            [key] => File:Russian_balls_12-13.jpg
            [title] => File:Russian balls 12-13.jpg
            [excerpt] => Description<span class="searchmatch">Russian</span> <span class="searchmatch">balls</span> <span class="searchmatch">12</span>-<span class="searchmatch">13</span>.<span class="searchmatch">jpg</span> Русский: Коньки (кость). Яйца-погремушки (глина). Мячи (кожа) - Новгород, Смоленск, Вщиж. Русь, XII - п.пол. XIII века
        )

)
Array
(
)
Array
(
)

The code is unable to get descriptions or thumbnails, so the arrays passed to array_merge are of unequal length, causing the issue.

This error used to occur semi-regularly but hasn't occurred since Jan 24th. @BPirkle are you ok if we close and (re-open) if it starts up again?

BPirkle claimed this task.

Closed, as this appears to be fixed. We can reopen if necessary.