Thanks! Confirming. Workaround: Enter not(wikibase-lua) per https://www.mediawiki.org/wiki/Phabricator/Help#Search_terms

Steps to reproduce:

Need steps to reproduce; please reset task status once provided

Ah, I think I understand now. Sorry!

The expected search result should be the same as https://phabricator.wikimedia.org/search/query/TKNMNOSJLu3e/, since we do not use tags on commits.

• If we use keyword only - no time out and I am able to browse all results
• use keyword and tag - timeout
• use keyword, tag and type - no timeout

Could you please answer my question?:

Could you elaborate which behavior you would have expected instead? If you expected lots of search results, then this task is likely "declined" though...

No issue if we only use a keyword and no tag, such as https://phabricator.wikimedia.org/search/query/JGEWQr3x7.VC/, provided the keyword is not a common one (cf T258803).

Do not think there are many search results.

Do not think there are many search results. Also there are no problem if we set another tag (e.g. srsearch with CirrusSearch).

In T263063#9086963, @Aklapper wrote:

Should it be upstreamed? Or not? I cannot reproduce locally (PHP 8.2) or in Phorge upstream though.

Cannot reproduce anymore with latest created accounts; if this happens again I should check https://phabricator.wikimedia.org/daemon/

This is a one-liner downstream patch we've been carrying around for three years which has not been upstreamed yet.

@valerio.bozzolan: Did you intentionally set yourself as task assignee?

any(mediawiki-action-api) works and is the canonical name of the project. #mediawiki-api is an additional hashtag.

Search for EchoPerUserBlacklist

title:growth title:hebrew (without AND) gives me two tasks:

We had a task to verify compatibility with ElasticSearch 7.10 then T303445#7807237 states Phabricator uses MySQL. From https://phabricator.wikimedia.org/config/cluster/search/ :

Elasticsearch since Phabricator uses that as backend:

phabricator_cluster_search:
  - type: 'elasticsearch'
    path: '/phabricator'
    port: 9243
    version: 5
    hosts:
      - protocol: 'https'
        host: 'search.svc.eqiad.wmnet'
        roles:
          read: true
          write: true

@Falloutgen for Wikimedia deployment we copy the composer dependencies to https://gerrit.wikimedia.org/r/mediawiki/vendor.git which has wmf branches as well. The reason is we do not run composer update on our production cluster, we instead rely on a copy of the dependencies stored in that git repo. Thus when deploying we would deploy mediawiki/core, extensions, skins AND mediawiki/vendor all using the same wmf branch (for example this week wmf/1.39.0-wmf.28). This way we have a guarantee the composer dependencies match the code.

Everything is good on our side, I can even say that on a non-wmf wiki, the modifications made by the equipped works with :
PHP 8.1
Elasticsearch 7.17.6

In T317284#8220122, @Falloutgen wrote:

Hello,

Good deduction, the error came from elastica which does not update its dependencies via compose in the main folder.

To solve the problem to ssh :
cd extensions/Elastica
Then
Composer update

Everything is now working normally in WMF28 and php 8.1, thanks :)

In T317284#8220099, @hashar wrote:

Do note that wmf branches are primarily intended for Wikimedia cluster deployment.

We try to follow this deployment cycle to anticipate as much as possible the updates and identify possible problems :)

Thanks a lot!

Good deduction, the error came from elastica which does not update its dependencies via compose in the main folder.

We are in process of upgrading our ElasticSearch cluster from 6.2.0 to 7.1.5, from the git log of the Elastica MediaWiki extension:

* 3ad0eb4 - (HEAD -> master, origin/wmf/1.39.0-wmf.28, origin/master, origin/REL1_39, origin/HEAD) Remove now unnecessary phan suppression (8 days ago) <Erik Bernhardson>
*   c8195dc - Merge "Switch to Elastica 7.1.5 [re-apply]" (9 days ago) <Ebernhardson>
|\  
| * 1245f59 - Switch to Elastica 7.1.5 [re-apply] (10 days ago) <Ebernhardson>
* | 66cd46c - (origin/wmf/1.39.0-wmf.27, origin/wmf/1.39.0-wmf.26) Merge "Revert "Switch to Elastica 7.1.5"" (3 weeks ago) <jenkins-bot>
|\| 
| * 1778a2f - Revert "Switch to Elastica 7.1.5" (3 weeks ago) <Ebernhardson>
* | 86110ec - (origin/es710) Merge "Switch to Elastica 7.1.5" (3 weeks ago) <jenkins-bot>
|\| 
| * d1c5a15 - Switch to Elastica 7.1.5 (4 months ago) <David Causse>

I added some more information because it seems that this problem comes from php 8.1 (for the search suggestion) and php 8.0 and 8.1 for CirrusSearch itself.
These two concerns were not present until now, we follow the wmf cycles in 8.1 the release of php 8.1.

The search scope is "Current Application" if you're in a Phab task. The search scope is global if you're on e.g. the Phab front page.
In general I recommend to use https://phabricator.wikimedia.org/maniphest/query/advanced/ for searching tasks.

In T252150#7981239, @Dylsss wrote:

Not sure if this is a new feature, but when you change the filter it posts to /settings/adjust/?key=search-scope. So you should only need to change it once. But the default can also be changed for everyone by administrators in the global default settings page.

Not sure if this is a new feature, but when you change the filter it posts to /settings/adjust/?key=search-scope. So you should only need to change it once. But the default can also be changed for everyone by administrators in the global default settings page.

I think this is the same as T291775 and T258803.

In T308946#7947338, @Aklapper wrote:

Cannot reproduce on https://phabricator.wikimedia.org/search/ . https://phabricator.wikimedia.org/search/query/_ndFuPQejqYu/#R lists results.

Cannot reproduce on https://phabricator.wikimedia.org/search/ . https://phabricator.wikimedia.org/search/query/_ndFuPQejqYu/#R lists results.

Indeed; the proper Maniphest search at https://phabricator.wikimedia.org/maniphest/query/IReCdyJDn.xF/#R also does not list any results