tree f1960001658b4ded2b3ea4c8a546dafc6822cd7d
parent bb2595108b3369d8b6b65fabee1de674249b7eac
author Dave Borowitz <dborowitz@google.com> 1553118571 -0700
committer Dave Borowitz <dborowitz@google.com> 1556809181 -0700

Populate CombinedCheckState in query path from a cache

We want to be able to serve combined check state in query results
cheaply in the common case. Recomputing the state from scratch is
expensive, as it requires:
 * opening the change repo
 * reading the check ref and note contents for the current patch set
 * reading checker configs for the repo
 * running checker queries to determine if the check state should be
   backfilled.

Introduce a mutable, optionally persisted cache keyed only by project
and change/patch set ID that stores the combined check state. This is
the simplest key that allows us to fill in many results quickly. Use the
"--combined" option in the query path as well.

To mitigate potential staleness in search results, put results into the
cache anytime the check state is updated or the combined check state is
recomputed from primary storage. To avoid too many writes to persistent
storage, we do a racy read-then-write and only update the cached value
if it differs. The assumption is that most updates to individual checks
will not result in the combined state changing. The raciness is
mitigated by the fact that we do this dance on every change screen load,
so it should converge to the right value regularly.

Include a metric recording latency of the reload step, keeping track of
whether the recomputation resulted in a write to the underlying cache.

The tests involving the metric highlight the fact that there are already
multiple places in the request path where we recompute the combined
check state. Exploring ways to reduce that duplicate work is beyond the
scope of this change. In the context of this change, at most one of the
duplicate recomputations will result in updating the cache.

Change-Id: I8ce16c979a0fc5697b0dd604e150481ef661fa16