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
aa03d40c1f