this will happen in cirrus, not as an elasticsearch plugin

As pointed out by Manybubbles this will be completely fixed once we fully get rid of elasticsearch query_string. This work is being tracked in T185108.

moving to waiting/blocked waiting for the hebrew plugin

If this submodule is not referenced by anything else other than mediawiki then there should be no reason to bump it in deployment-prep, I'd be for resetting it to 4db9d40d28d61c53cdbca77059d9a2a6e714af89 to match prod.
Side note: I'm pretty sure that https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/300880 was unnecessary. This submodule in mw-config is not meant to be updated whenever a change to it is applied, only when schema used by MW is updated.
Then to the question: why event-schema was bumped directly on deployment-tin? I have no clue, so if nobody requires it I'd be for cleaning it and align it to prod.

thanks!
this works as expected now.

Pinging @Pchelolo as he may use this repo for testing purposes.

Found a possible reason for this to happen and filed a bug upstream: https://github.com/elastic/elasticsearch/issues/32467
In short the completion suggester code does handle gracefully shard failures during the fetch phase causing the response received by cirrus to not contain the necessary information.

will try to look at this again

by forking the elasticsearch and use github zip export I could find a way to make it work, now cirrus tests are failing.
This should at least allow us to move forward.

Preliminary package (without hebrew) available at : https://people.wikimedia.org/~dcausse/wmf-elasticsearch-search-plugins_6.3.1-alpha1~jessie_all.deb

I'm stuck on this because we still have to support HHVM but unfortunately we can't activate hhvm.php7.scalar_types (see T173786#3688184). The new elasticsearch php client has many statements such as declare(strict_types = 1); which triggers this fatal error:
Fatal error: strict_types can only be used when hhvm.php7.scalar_types = true

Happened today again on elastic1030,

clean_api_prefix_redirect_accent_squashing_accented_namespace_suggest_search_prefers_main_namespace_over_crossns_redirects seems due to a instability in the scoring function:

clean_api_update_deleted_redirects_are_removed_from_the_index can be explained because of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/445581

@Johan thanks for the feedback!
Yes the goal is really not to remove the prefix keyword, expert users will still be able to use it at will.
I'll move forward and implement your suggestions on the phrasing and wait till the end of next week for possible feedback from the Tech News.

Without the full stacktrace I'm not entirely sure that the attached patch will fix the issue but I've seen similar behavior while upgrading to 6.3.
I suggest to wait and see if the error disappears after we migrate to 6.3.

In T198851#4402862, @Johan wrote:

A couple of questions!

a) The goal here is to make it easier to understand, less confusing for non-technical readers and editors? Or something else?

just to add a note that I discovered this morning that elastic will refuse to boot if the other cluster you setup like:

search:
        remote:
                other:
                        seeds: 10.11.12.1:9300

In T198318#4326333, @Smalyshev wrote:

So do I understand right that the proposal is to keep the prefix URL param, but instead of handling it by messing with query string, handle it by adding a filter in search context? If so, I think it's the right thing to do.