commit aa03d40c1f6d63636b363df0369631278dc47773
author Dave Borowitz <dborowitz@google.com> Thu Jun 02 15:13:41 2016 -0400
committer Dave Borowitz <dborowitz@google.com> Fri Jun 03 10:04:10 2016 -0400
tree 69a065c9a9364f6cd4a8540de1085c7751ec14ed
parent c7bb599d75dd4ce5c2dd45c993d91b4d63c64975

Selectively ignore errors from NoteDbUpdateManager

As we know by now, NoteDb writes can fail for all sorts of reasons.
In the case of writes via BatchUpdate, from the user perspective we
don't actually care if the NoteDb update fails. If NoteDb reads are
enabled, we want the change to get rebuilt on the next read, but that
will happen regardless of whether or not BatchUpdate throws an error,
because we've already saved the data in the canonical location in
ReviewDb. Users prefer not to see errors, so just ignore them.

Another somewhat related issue is what to do about errors during the
auto-rebuild codepath during read. These have been cropping up
unpleasantly frequently due to the behavior of the change screen,
which sends a bunch of parallel requests all reading from the same
change entity. This is racy and tends to result in a noticeable
subset of requests getting LOCK_FAILURE and throwing. In this case,
the caller does actually care that the change got successfully rebuilt
after we detected it as stale--we can't just ignore the error. But it
doesn't actually matter that *this caller* was the one to rebuild the
change. We can just reread the NoteDbChangeState from ReviewDb and
compare it to the new value of NoteDb after an exception to see if it
got rebuilt behind our backs. Only go arm's-length here and retry
once; rebuilding in a loop seems risky.

Both of these cases are actually quite straightforward to fix; the
annoying thing is injecting a test ChangeRebuilder implementation
that's capable of doing the update behind the caller's back.

Change-Id: I0b80c97552cbdbfc6de44a785b41ad7ad8ab05b0