tree f6698430ad9b67f1219f3dcbd5e95b2e6a188fc0
parent a4a8e5591816c5399cd1b6b4aa3b8ff86572dea7
author Edwin Kempin <ekempin@google.com> 1560850934 +0200
committer Edwin Kempin <ekempin@google.com> 1563458427 +0200

Automatically retry REST operations on failure with tracing enabled

On REST endpoint level we already retry the REST operation if there was
a potentially temporary failure such as a LockFailure. Extend this to
also retry once on non-recoverable failures, but with request tracing
switched on. This is the same as if the user would retry the REST call
with request tracing after it has failed. Capturing traces for failures
automatically can help with debugging issues and safe roundtrips between
user and supporting engineer.

This only works for REST endpoints which support retrying (REST
endpoints that extend RetryingRestModifyView or
RetryingRestCollectionModifyView). Enabling more REST endpoints to retry
is outside the scope of this change, but surely feasible.

Submit has custom retry login in MergeOp. Adapt the retry in there too.

Whether retry on failure should be done can be configured by setting
retry.retryWithTraceOnFailure in gerrit.config (default = false).

Since not all REST endpoints are atomic it can happen that a REST
endpoint did some partial updates before it failed. If the operation is
retried, in this case it can happen that this partial update is done
again or that the failure is different now. This is OK since the chances
for this are low and the same would happen if the user retries the
operation.

Change-Id: I2b78cbef50e5c3ce4fafce0d7cdcb3b1835abc86
Signed-off-by: Edwin Kempin <ekempin@google.com>