| • Lucas_Werkmeister_WMDE | |
| May 4 2022, 1:51 PM |
| F35102517: Screenshot from 2022-05-04 15-56-39.png | |
| May 4 2022, 1:56 PM |
In wmf.10 (T305216), the wbsearchentities API doesn’t seem to find any search results anymore, except for exact entity ID matches. (For example, searching Q42 finds Q42, i.e. Douglas Adams, but should also find Q42395533, the item about Q42. Searching Douglas Adams produces no results.)
The main end user-visible impact was Wikidata autocomplete not finding any result (adding this to avoid duplicate reports, as we got some users noticing this).
I already noticed this on testwikidata earlier today, when (I think) wmf.10 was only on group0, but didn’t have time to follow up before wmf.10 moved ahead to group1 (which includes Wikidata).
I suggest rolling back wikidatawiki, and only wikidatawiki, to wmf.9.
Special:Search seems unaffected, but the practical impact of this is that manual editing of Wikidata, as well as Structured Data on Commons, becomes extremely tedious, or almost impossible, because wbsearchentities powers the entity selectors:
Note: this indirectly affects Commons (via Structured Data), but I don’t believe it’s necessary to roll back commonswiki to wmf.9, because the relevant search requests already go to www.wikidata.org.
Change 789160 had a related patch set uploaded (by Hashar; author: Hashar):
[operations/mediawiki-config@master] Revert "group1 wikis to 1.39.0-wmf.10 refs T305216"
In addition to the fix/rollback- could some integration test or heuristic production monitoring also be able to be implemented, for future faster detection?
Mentioned in SAL (#wikimedia-operations) [2022-05-04T14:10:10Z] <hashar@deploy1002> rebuilt and synchronized wikiversions files: wbsearchentities produces no result T307586
Change 789160 merged by jenkins-bot:
[operations/mediawiki-config@master] Revert "group1 wikis to 1.39.0-wmf.10 refs T305216"
@dcausse I think y’all have been doing some work on elasticsearch compatibility in (Wikibase)CirrusSearch (T288765 and some other changes), any chance this could be related? I don’t see anything in the Wikibase.git log that looks like a likely culprit. (The issue can still be reproduced on Test Wikidata, e.g. search for a. I can’t reproduce it locally yet, which I assume is because I don’t use CirrusSearch locally.)
@Lucas_Werkmeister_WMDE maybe that can be reproduced on testwikidatawiki https://test.wikidata.org/
There is a variety of churn in Cirrus right now related to a version upgrade which likely caused this. Will look what is causing the breakage today.
Change 789227 had a related patch set uploaded (by Ebernhardson; author: Ebernhardson):
[mediawiki/extensions/WikibaseCirrusSearch@master] Search against index instead of type
Patch should resolve the issue. In terms of testing I would estimate that only integration testing would reliably catch this type of problem. We have some of that in CirrusSearch itself but nothing I'm aware of for the specialized wikidata extension.
Change 789174 had a related patch set uploaded (by Brennen Bearnes; author: Ebernhardson):
[mediawiki/extensions/WikibaseCirrusSearch@wmf/1.39.0-wmf.10] Search against index instead of type
Change 789174 merged by jenkins-bot:
[mediawiki/extensions/WikibaseCirrusSearch@wmf/1.39.0-wmf.10] Search against index instead of type
Mentioned in SAL (#wikimedia-operations) [2022-05-04T19:47:51Z] <brennen@deploy1002> Synchronized php-1.39.0-wmf.10/extensions/WikibaseCirrusSearch/src/WikibasePrefixSearcher.php: Backport: [[gerrit:789174|Search against index instead of type (T307586)]] (duration: 00m 52s)
Change 789227 merged by jenkins-bot:
[mediawiki/extensions/WikibaseCirrusSearch@master] Search against index instead of type
For Tech News purposes, how should this entry be described? IIUC from the description, something like this?
There was a problem with Wikidata's search autocomplete last week. This has now been fixed.
Please approve that wording, or suggest a better summary. Thanks!