There is a discrepancy for langues where we do not apply any accent folding. We always apply accent removal (with either asciifolding or icu_folding) on autocomplete and go but we do not on fulltext.
This is inconsistent, I think we should query all_near_match.asciifolding alongside all_near_match for fulltext queries.

it's happening again on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/516637 :

07:16:01 Undefined index: imageinfo
07:16:01 
07:16:01 /workspace/src/extensions/WikibaseMediaInfo/tests/phpunit/integration/WBMIApiTestCase.php:118
07:16:01 /workspace/src/extensions/WikibaseMediaInfo/tests/phpunit/integration/MultiLingualCaptionsTest.php:28
07:16:01 /workspace/src/tests/phpunit/MediaWikiTestCase.php:427

I changed the output to:

{
  "wmfMasterDatacenter": "eqiad",
  "wmfEtcdLastModifiedIndex": 3672,
  "wmgCirrusSearchDefaultCluster": "local",
  "wgCirrusSearchDefaultCluster": "eqiad"
}

possibly related to the patch merged on T214494

Tested various PHP versions hoping to find an explanation in vain.
Moving forward I think I'll add some temporary code in cirrus to detect invalid UTF-8 sequences in the source text so that we can flag and fix such pages in the elasticsearch index. Since Cirrus is refreshing its index constantly we might be able to use its data to filter the list of non-deleted pages that contain invalid UTF8 sequences in their text content.

Checked few examples and there seem to be a mix of

• LiquidThread pages
• old pages in (generally CJK languages) and do not seem to have been updated in a while (~2004)

This error is not new, it's just that we changed some class names (message:"Unable to serialize events" AND exception.trace:"CirrusSearch"). Removing from deployment blocker.
I think it's caused by something similar to T184698

I finally opted for a randomized approach where I limit the number of fixture at 200 by default per run. The fixtures to test are selected randomly. If merged the full suite of unit tests for Cirrus would now take 25sec instead of 1m30 on my laptop.

we blindly copied all browser tests fixtures and run them on 3 different setup, I'm sure we can prune down the list of tested cases.

@Smalyshev I totally agree, I was suggesting a UX where a first attempt search would try to match using the haswbstatement keyword (switched to case insensitive) and then a second try could be made using the fulltext mode if the first attempt is unsuccessful.

we should also note we index this data in the main filter field which means that for searches that are unlikely to be ambiguous (IDs and such) one could simply search for 10.1371/journal.pcbi.1002947. Benefit is that it's tolerant to small variation in punctuation but also accept partial searches like:
journal.pcbi.1002947 or even with small variations: journal pcbi 1002947.

@Smalyshev switching the main field for statements to lowercase_keyword won't break anything, it's like a new field it'll be taken into account just after the next reindex. I would advise against a new field here, the cardinality would nearly double.

yes, we need to find a good way to version cirrus indeed :)
I was thinking of aligning it to the version of elasticsearch it supports. We should be at something like 6.x.

In T224448#5216526, @thcipriani wrote:

In T224448#5216469, @dcausse wrote:

Here SendEmail-1 is not "blocked" it's just waiting for jobs, however the dump says:
Locked ownable synchronizers:- <0x00000001c13617f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync).
Meaning that this SendEmail-1 thread holds the ReentrantLock lock which is blocking Http threads.
So something happened previously in that thread that caused the lock to still be held.

Is it also possible that it's some kind of blocking read causing a deadlock that doesn't show up in dumps? i.e., https://dzone.com/articles/java-concurrency-hidden-thread

Here SendEmail-1 is not "blocked" it's just waiting for jobs, however the dump says:
Locked ownable synchronizers:- <0x00000001c13617f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync).
Meaning that this SendEmail-1 thread holds the ReentrantLock lock which is blocking Http threads.
So something happened previously in that thread that caused the lock to still be held.

Looking at the URL (crazy offset usage) I think it's related to T223738 and already fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/511455

This is using the simple search form (triggered from the search box top-right): https://phabricator.wikimedia.org/search/query/ZRnM6OqnN6iE/#R (this current task should be present in the search results)
Thanks for pointing at the advanced search form I was not aware of it.

Is this a regression?
At a glance I don't see the parser function coordinates being called when parsing for instance Bratislava. If this is a regression would it be possible that a change to a template on-wiki caused this?
Testing the parser function {{#coordinates:48.143889|17.109722}} I can see the coordinates being indexed but I failed to use templates such as {{Súradnice|48.143889|S|17.109722|V|format=dms}} in such case the coordinates does not seem to be sent to the coordinates parser function.