MergeOp: Retry when current revision is not found
We were unconditionally setting the change back to NEW if there was
some unknown error attempting to merge a change. Be a little more
precise about what we do with REVISION_GONE. In particular, in a
replicated environment with eventually-consistent semantics (whether
master-slave or multi-master), a revision might be missing due to
replication lag, which might eventually correct itself. So, we
shouldn't reset the change to NEW in this case, allowing the submit
queue to eventually pick it up once replication settles out.
We can also make the message a little nicer. Like other merge failure
messages, this one is repeated only occasionally if it is a duplicate.
This does mean that if the failure is not due to replication lag but
something else (the kind of thing this code was originally worrying
about, e.g. the ref got manually deleted), we might continue retrying
indefinitely. This is not so bad; there are already plenty of cases
where we do that, and that's why we implemented the message
deduplication in the first place.
Change-Id: I2f8d2ab1bc3938dbc0573dc5a319f03bb546b5f1
1 file changed
