tree a8b70165e0f9b86b135dc756314e9f9262dbcfca
parent 91e5198448305dd89c9e9d5d7ce5757ddf0e8b72
author Antonio Barone <syntonyze@gmail.com> 1706038857 +0100
committer Antonio Barone <syntonyze@gmail.com> 1707225446 +0100

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