@GWicke: Got a testcase what you enter literally and what you expect to show up?

Same for me. In the case of Services, we have multiple tags connected to our board, services (done) and services (watching) to name just a few. Until a while ago, if I type services (d the completion thingy suggested me the correct tags, but now they are not showing up any more.

In certain circumstances I am able to get Phab to show me the tags, but I yet have to understand the exact scenario in which that happens.

Oh, and another thing. Even though these tags are effectively columns on our workboard, I cannot use the Move on workboard action to move the task to another column, only Backlog is displayed in the drop-down.

Interesting that there is a work-around, though. Hadn't thought of typing "services d" to get "Services (doing)".

Before the upgrade, just typing "services" would list all the milestones.

I'll just boldly CC @epriestley here. (Evan, please feel very free to unsubscribe yourself again.)

In T152726#2858480, @GWicke wrote:

Interesting that there is a work-around, though. Hadn't thought of typing "services d" to get "Services (doing)".

It doesn't always work, though. Also typing services [d sometimes gets you that. But only sometimes.

Looks like a good candidate for T151500: Collect test cases for phabricator search.

Maybe it is related to the switch from MyISAM to InnoDB which have different search behavior. That got discussed on T146789. T146843 is the task to track the reevalatuion of the search engine and maybe switch to ElasticSearch (??).

Note that searching for the milestone name (without the parent project) seems to find them reliably...

e.g. typing upstream finds Phabricator (upstream)

Seems like the fuzzy filter doesn't like '(' in the search terms but also doesn't tolerate more than a couple of characters of mismatch between the tag name and the search input.

In my exp, typing done has never turned out Services (done)

Although there's no way to know this without knowledge of the internals, typeaheads are (almost) completely separate from fulltext search. From an upstream perspective, it's most helpful if fulltext test cases and typeahead test cases can be separated since we're likely to tackle them mostly separately (although you can merge them together here and we can sort it out later if that's easier, of course). In particular, my expectation is that InnoDB/MyISAM/fulltext changes will usually not impact the behavior of typehead search.

I'd also ideally like to build a "what does this object look like in the search index?" or "what is search doing?" sort of view to make it more clear how search is working (and at least make it easier to find workarounds until we can fix issues), but I'm worried that's going to end up creating a series of policy violations by letting you see that something you don't have permission to access has been indexed. After some thought, I can't come up with an approach for this that I think would both be materially useful and which I'm confident will actually be safe (I do have a few minor changes in mind to make some aspects of search more clear).

Upstream task for this is likely: https://secure.phabricator.com/T11955

I'll take a look at what's going on here and continue things upstream if there's a bit of a mess.

I think this is now (well, shortly) fixed upstream, likely available here after the next upgrade. See https://secure.phabricator.com/T11955 for some additional discussion.

Mentioned in SAL (#wikimedia-operations) [2016-12-10T04:21:08Z] <twentyafterfour> deployed hotfix for T152726, restarted apache on iridium

Hmm, hotfix doesn't seem to do the trick.

Did you get rPHAB9c38b61e51a053f8aafe96bcc6b99291a1fe4bd3 too, and run bin/search index --type project --force afterward?

Awesome! Let us know if you catch any more issues.

Confirmed fixed. Thanks a lot!