Typeahead returning only archived results


…in particular, it’s only returning archived results if there are more than 100 archived projects that meet the search term, even if there are non-archived results further along.

Observed Behavior:
The typeahead suggestions are only returning archived results for a query that returns more than 100 (archived) results, even if there are non-archived results further along. This appears to affect both the Maniphest “Add Project Tags” typeahead and the Global Search typeahead.

The current results for a typeahead in our Phabricator instance.

(The search box through the magnifying glass also fails the “sprint” search case now–it does return a “more results” tag but projects are still missing until the search is refined enough to bring the list of archived projects under the 100 limit.)

In the case of our install, we use tags for weekly sprints, and each of our tasks is triaged with the appropriate tag, usually by typing as much of the word “sprint” as necessary in the typeahead to return the most up-to-date tag. A few weeks ago it seems we have reached over 101 archived sprint tags, and after that point the query began returning archived results instead of the active sprint tags that it used to.

The request to URL [PHABRICATOR_BASE_URL]/typeahead/class/PhabricatorProjectDatasource/?q=sprint&raw=Sprint&__ajax__=true&__metablock__=7 (or request to /typeahead/class/PhabricatorSearchDatasource/?q=sprint%20201&raw=sprint%20201&__ajax__=true&__metablock__=20 for the Global Search) only returns the first 100 results (of 109 in the database for the query it uses to find “sprint”, three of which are active projects). All of the returned results are archived, as usually only the last two or three projects (in order of date created) are unarchived in our install.

If you type most of the project name (eg: ‘Sprint 2018’ to try to find the project ‘Sprint 2018-51’), or enough of the tag to return less than 100 results, the typeahead works as expected.

Expected Behavior:
Either only the non-archived results for the query, or the results with the non-archived projects prioritized at the top of the typeahead. It used to do this, so staff are expecting to be able to type “sprint” in the typeahead and grab the first result for the most up-to-date tag.

Phabricator Version:
phabricator 9e50864d425129600d82700093f34f2d5d9f4cd1 (Mon, Dec 17) (branched from 5e94343c7d1ac87f1c4621c503373e88ddc892e3 on origin)
arcanist eb732555a71a3a1b15596dd65b6dad3c2e2af90b (Wed, Dec 12)
phutil cad1985726c99e1225b95abf8a2bd1601a267fe4 (Thu, Dec 13)

Reproduction Steps:

  • Have an instance with 100+ archived projects that share a term (eg: “sprint”), preferably with some sort of order. (In our case, it’s organized by year/week, much like the Phabricator releases–eg: “Sprint 2018-01” to “Sprint 2018-52”, all the way back to 2016.)
  • Have at least one or two un-archived projects that share the same term. (In this case, all but the most recently-created two or three projects are generally archived.)
  • Attempt to tag a Maniphest task with the un-archived project name
  • If the query returns more than 100 results, only “Archived” results will be returned in the typeahead (or the /typeahead/class request)

My guess is that the typeahead is truncating the returned results to be a more reasonable result set per the limit (100?). Is there a way to increase the limit/alter the sorting so that it tries to check the archive status before truncating?

In the meantime, we’ve just prefixed all of the previous year’s sprint projects with “Archived” to take advantage of the prefix sorting and get the typeahead to behave as expected again.

Thank you!


From further digging in hopes of maybe patching something ourselves, it looks like we’re hitting this case from https://secure.phabricator.com/T12538:

Datasources may eventually need to perform equivalent ranking, but the scenario which breaks is obscure and would already cause issues. It looks like this:

  • Users abc001, abc002, …, abc100, all disabled.
  • User abc101 is enabled.
  • You type abc.
  • abc101 should be the top hit, but will not be part of the result page because there are 100 other results, so it will not appear. (You can find it by querying for abc1 instead.)
  • This is a pre-existing problem with filtering, too, and can be remedied through server-side pre-sorting or datasource query phases (D16838) if it ever occurs. It is possible it may occur for projects in the wild eventually, for example with 100 disabled milestones.


Thanks for the report, this should be fixed in https://secure.phabricator.com/D19907.


That’s awesome! Thank you so much @amckinley!

Can confirm, patching those changes into our install does fix the issue.