commit aa47a16ae008b71ba4c9c23820ad3e438bb48348
author Logan Hanks <logan@google.com> Mon May 08 15:37:05 2017 -0700
committer Logan Hanks <logan@google.com> Mon May 08 16:53:20 2017 -0700
tree be0ceb6cefbd6e9e9dc2ab8ee35b24a9a62e84aa
parent 368c922dfc88323df2efe037691433c8fb91e538

Limit expansion of accounts for default fields

Terms in search queries that aren't qualified by a field are replaced
with an expansive OR predicate that applies the term to a number of
hard-coded "default" fields. Two of these default fields, owner and
reviewer, are designed to match against account IDs.

To construct an owner or reviewer predicate, we immediately resolve the
term to a set of matching account IDs, wrapping each with the specific
predicate for the field, collected by a single OR predicate. For
example, if the query [hi] resolves to three accounts, then the default
field predicate might expand to something like:

    (OR
      (OR (owner acct1) (owner acct2) (owner acct3))
      (OR (reviewer acct1) (reviewer acct2) (reviewer acct3))
      (file "hi")
      (project "hi")
      ...
    )

On a site with many users, a short term can resolve to hundreds of
accounts. Adding two very large predicates in such cases can lead to
very innocuous queries like [hi] resulting in a "too many terms" error.
The error is due to protection of the search backend from denial of
service by superficially examining the "cost" of the query, which is
proportional to the size of the predicate tree. As a site gathers more
users, this error is increasingly likely to occur (as observed in issue
6118).

To resolve this, we simply omit owner and reviewer predicates from
default field expansion when they are overly large. This commit sets the
maximum number of accounts per default field to 10 as a hard-coded
constant. Explicit uses of owner and reviewer fields are unaffected by
this limit. It only applies during default field expansion.

Bug: Issue 5856
Change-Id: Ibf6960976122e8170954ec20d3df9b50f597c5f7