A recent (~last two weeks) Phabricator upgrade seems to have broken completion of milestone tags in the task edit "tags" widget. This effectively makes those tags inaccessible from the regular task edit workflow. The only remaining way to add those tags seems to be to a) tag the task with the parent project, b) go to the parent project's workboard, c) find the task in question, and d) drag it from "backlog" to the desired milestone. Needless to say, this is quite cumbersome, and negates the main benefit milestones originally brought.
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.
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 (??).
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.