Closed justinlin-linkedin closed 1 month ago
Attention: Patch coverage is 80.55556%
with 7 lines
in your changes missing coverage. Please review.
Project coverage is 70.24%. Comparing base (
52ba813
) to head (a65d74e
). Report is 51 commits behind head on master.
Files | Patch % | Lines |
---|---|---|
.../java/com/github/ambry/router/DeleteOperation.java | 81.48% | 0 Missing and 5 partials :warning: |
...ava/com/github/ambry/router/NonBlockingRouter.java | 60.00% | 2 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Summary
Issue a force delete request when the delete request is getting 503.
Details
When originating replicas returns more than 1 unavailable to frontend for delete operations, we have to return 503 back to client since we can't be sure about the status of the blob. If we have two unavailable hosts, (due to any reason, server busy, server unavailable, etc), it's impossible to know if this blob exists on these two hosts or not. In this case, we have to return 503 so client can retry later.
However, when executing delete, in most cases, we know it would be fine to place a delete tombstone to available replicas and just return 200 back to client, since the delete is the final state.
There are some catches here. If the cluster enables undelete, we might have some unavailable replicas that have blob at certain lifeVersion. A force delete would place a delete tombstone with life version 0, which will be overritten by the higher life version later.
Test
Unit tests.