tree 1cf97d1cb81a7667c2151f96882696374ad826f7
parent e13124f6063a0620c56e18e4f7a8bf55d8ee51bd
author Antonio Barone <syntonyze@gmail.com> 1706038857 +0100
committer Luca Milanesio <luca.milanesio@gmail.com> 1774877226 +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