In T12450#216943, @epriestley wrote:

---

• Searching for f*a*c*t*o*r*y*s*u*r*p*l*u*s*z*z*q*q*z*z*q*q produces nonsenical results (many results, when I would expect no results: the results do not contain that sequence of letters in order).
• Searching or user fails to find task Grant users tokens when a mention is created, suggesting that stemming is not working.
• Searching for users finds that task, but fails to find a task containing "per user per month" in a comment, also suggesting that stemming is not working.
• Searching for maniphest fails to find task maniphest.query elephant, suggesting that tokenization is ElasticSearch is not as good as the MySQL tokenization for these words (see D17330).

f*a*c*t*o*r*y*s*u*r*p*l*u*s*z*z*q*q*z*z*q*q returns the same results as
f a c t o r y s u r p l u s z z q q z z q q so it appears to be treating those as individual single-letter tokens. strange.

I think it would make a lot of sense to construct the two queries separately (and in parallel) with a short timeout, then handle the timeout gracefully allowing the user to refine their query further. This would avoid the denial of service situation which happened to Wikimedia more than once due to users repeatedly executing really expensive searches until mysql fell over from the load.

And also, there's no edit form below this kind of task:

The high level need here actually just came up as recently as yesterday with our new senior product manager; he had no idea that there was a Maniphest-specific search and had instead been searching for maniphest tasks using global search (and was convinced Phab search was very limited due to this). Only upon me watching him do this search and advising him did he discover it. I've seen this issue several times now in our organization and I believe it contributes to the perception from some people internally that they have problems with Phab search.

FWIW I don't see this as something people would express interest in so it doesn't surprise me you haven't heard it from people, but if a user discovered it (e.g. there were an indicator below/during a search query as a power feature), I imagine they would use it. Just my 2 cents.

In T12450#216943, @epriestley wrote:

I ran into a lot of confusion because the versioned object indexes are not namespaced per-service. Basically, if you insert version 95 of a document into Elastic, the indexer thinks that version 95 doesn't need to go into MySQL, even though it does. So when you run bin/search index ..., you may get only a subset of the updates you actually need. The object index versions need to change to become engine-aware so they are stored per-service, not globally, and/or the whole mechanism needs to include a hash of cluster.search or just be turned off. Until this is fixed, it can be worked around with using --force everywhere.

bin/search index might reasonably provide summary output about this ("392 documents were not indexed because they haven't changed, use --force to update them.").

In T12450#216943, @epriestley wrote:

---

• Searching for f*a*c*t*o*r*y*s*u*r*p*l*u*s*z*z*q*q*z*z*q*q produces nonsenical results (many results, when I would expect no results: the results do not contain that sequence of letters in order).
• Searching or user fails to find task Grant users tokens when a mention is created, suggesting that stemming is not working.
• Searching for users finds that task, but fails to find a task containing "per user per month" in a comment, also suggesting that stemming is not working.
• Searching for maniphest fails to find task maniphest.query elephant, suggesting that tokenization is ElasticSearch is not as good as the MySQL tokenization for these words (see D17330).
• Searching for users -blue returns a huge number of results: significantly more than users. Expected behavior: fewer results, omitting those results matching blue.
• Searching for users blue returns more results than users or blue. Expected behavior: fewer results, because only results which match "users" AND "blue" are returned. The result set includes completely irrelevant results.

@epriestley: Thanks for the detailed feedback... I'll get to work ;)

(This was incorrectly closed by the text "doesn't actually fix T8918" in rP08de131da525.)

Personal notes:

In T12450#216917, @20after4 wrote:

I can not reproduce it on wikimedia's install.

Presuming this is resolved since @20after4 couldn't reproduce it after T12450, feel free to follow up there or in a new task if you're still seeing issues.

• Has T8602 been resolved?

I can not reproduce it on wikimedia's install.

I don't plan to implement the original feature as described.

We haven't seen significant additional interest in this in more than a year. I expect to implement T7860 but, not a query microlanguage.

• Write an "Upgrading: ..." guidance task with narrow instructions for installs that are upgrading.

TODO

• Do we need to add an indexing activity (T11932) for installs with ElasticSearch?

Yes, I think so

• We should more clearly detail exactly which versions of ElasticSearch are supported (for example, is ElasticSearch <2 no longer supported)? From >T9893 it seems like we may only have supported ElasticSearch <2 before, so are the two regions of support totally nonoverlapping and all ElasticSearch users will need to upgrade?

Presuming this is resolved by D17384, see T12450 for followups.

Presuming this is resolved by new indexes in D17384, see T12450 for followups.

This was tagged ElasticSearch and may now be resolved (see T12450) but also lacks information we require in a modern bug report (specifically: precise reproduction instructions). If this is still an issue at HEAD of master, feel free to follow up on T12450 or file a new report with reproduction steps.

I haven't been testing with elasticsearch < 2.0 so this might break backwards compatibility. It wouldn't be difficult to fix any compatibility issues though, with a tiny bit of testing.

Presuming this is resolved by D17384 (but maybe @20after4 can correct me).

Presuming this is either resolved by T9893/D17384 or no longer relevant. Follow up on T12450 or file a new task if you're still seeing issues.

With the elasticsearch 'simple_query_string' query parser it only works if you use *pricot, for example, outside of quoted phrases.

I'm just going to close this in favor of T12450.

As a general product decision, I do not expect search to be substring search by default -- searching for pricot on Google does not match documents containing apricot. But we can sort this out in the long run.

Note there will finally be a little bit of documentation once this install rebuilds diviner docs: The url should be https://secure.phabricator.com/book/phabricator/article/cluster_search/ (eventually)

This should work just fine with the index mapping and query generation in {rPe41c25de5050}

Wohoo, yes it does.

I have a script like:

If only Phortune had an inventory management system.

Also ordered hoodies.

These are now up to date.

Where / how are you trying? Pages view library is /src/view/page/.

Tried numerous ways to do so.
Always failed with it.

In T12447#216806, @epriestley wrote:

But if you say "Haskell" you may have to wait a minute.

I'm going to presume this is approximately resolved.

Raw HTTP is actually perfect for me! Thank you!

But if you say "Haskell" you may have to wait a minute.

Maybe easier would be for you to tell me what language you want to use and I'll just write you a snippet which encodes a request?

The page implies that all I should need to do is POST up, for example, the following:

To be clear though, I still haven't figured out how to actually put in a POST body. It's fine to use URL params for something like differential.querydiffs, but I can imagine the problems I'll run into with URL length when doing harbormaster.sendmessage (especially when reporting a bunch of unit test and linting results).

(In the longer term, the permissions here could probably be cleaned up, but I think that's the cleanest fix without upstream changes.)

You can edit the "Create Form" form and change "Visible To:" to "Members of Project: Doctorate in Form Theory". Then only members of that project will be able to create other forms or edit the form form, I believe.

Enabling that form seems to have done the trick -- thanks! Since it got renamed at some point from "Create form," its existence was almost certainly confusing to some previous admin, which is what got us into this.

Ah. I think you'd just see this, then:

FWIW, All packages in our monorepo have weak dominion.

Overall, you only get checkboxes for users, packages and projects which are already reviewers, with the exception that you'll get one for yourself if you aren't a reviewer yet.

I think there is also zero legitimate reason for the form-configuring-form to be editable and this entire workflow essentially represents a trap for the unwary.

If you can't enable that form, you might need to go hunt it down in the database and manually enable it (or tell me what you hit and we'll fix it if it's a bug).