Page MenuHomePhabricator

task search not finding task with full word match
Closed, ResolvedPublic


The current search seems to have trouble matching full words from the title in some cases. Example from secure (query string typed into global search from home page):

Maybe because of the punctuation in the title?

Event Timeline

neilfitz added a project: Restricted Project.Feb 9 2017, 2:52 AM
neilfitz added a subscriber: neilfitz.

Hey, one of our teams is experiencing this issue as well - many of their tasks include the name of a flag with a lot of punctuation, such as subgrowth_biz_buy_order_summary. At some point in the not-terribly-distant past, searching for these flags started to return 0 results.

Putting quotes around the search seems to be a viable (if non-obvious) workaround. For instance, in this example:

yields the correct results, with T6771 at the top.

Maybe phabricator should automatically try adding quotes to a search if the initial query returns zero results?

Interestingly, phabricator_maniphest maniphest_transaction gives zero results but "phabricator_maniphest" "maniphest_transaction" works. Seems like the underscores are a problem as much as the period.

We transform x y into +"x" +"y" in the general case, but currently apply stemming to "a_b" and "c.d". This is because it's generally correct to stem "x-y", which is usually a hyphenated English phrase rather than a "constant" or "token", and correct to stem "z.", which is usually something copy-pasted with a stray period, not an intent to search for a token ending with a period, and the cases of "_" and "." got lumped in with those.

D17330 special cases "a_b" and "c.d" to be immune from tokenization or stemming.

I think you don't need to rebuild the search index for that to take full effect. Although rebuilding it will change the content in the index in some cases, the new, more-tailored queries should match either version.

Before rushing to update, note that there's a gaping maw of firey pain in master right now (see T12237), although this change is safe to cherry-pick to any older version it applies cleanly to.

I've upgraded this install, and the original reproduction case appears to be resolved: