Properly propagate failure when ref deletion fails
Refs deletions are implemented via the `DeleteCommand.deleteRef()`
method which attempts to delete refs locally after checking for
permissions and relevant configuration settings (i.e. `isMirror` flag).
Exceptions thrown during the deletion are then propagated to the caller,
which is correct, in order for the caller to take appropriate actions.
The problem however, is that not every ref deletion failure causes an
exception: failures are also represented as a result status of the
delete operation.
Take for example the existence of a ref lock on the ref being deleted:
this will cause the delete to return `LOCK_FAILURE`, rather than
throwing an exception.
However, because failure results are completely ignored, every
ref-update deletion that is not causing an exception is erroneously
treated as successful.
This behaviour impacts, as an example, the
`/pull-replication~batch-apply-object` and the
`/pull-replication-apply-object` HTTP endpoints, which invoke
`DeleteCommand.deleteRef()` when handling the deletion of a ref.
In case of an exception the endpoints will return the relevant HTTP
status code, informing the client of the failure, in all other cases
(even upon failing result statuses), the endpoint will erroneously
report success, misleading the client into believing that the deletion
was successful.
Stop ignoring the result statuses of ref-update deletions so that
callers can be made aware on the actual result of the failure and take
appropriate action.
Bug: Issue 288965464
Change-Id: Ib49247a1bb167c0b265151a1b1f5a6be15006012
4 files changed
