Unexpected object delete response code #197
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#197
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Expected Behavior
When I try to delete already removed object, I receive OK according to specification:
// - **OK** (0, SECTION_SUCCESS): \
// object has been successfully marked to be removed from the container;
// - Common failures (SECTION_FAILURE_COMMON);
// - **ACCESS_DENIED** (2048, SECTION_OBJECT): \
// delete access to the object is denied;
// - **LOCKED** (2050, SECTION_OBJECT): \
// deleting a locked object is prohibited;
// - **CONTAINER_NOT_FOUND** (3072, SECTION_CONTAINER): \
// object container not found;
// - **TOKEN_EXPIRED** (4097, SECTION_SESSION): \
// provided session token has expired.
Current Behavior
When I try to delete already removed object, I receive
code = 2052 message = object already removed
, which is unexpected because it isn't mentioned in the spec.Possible Solution
Update the spec and move this issue in the frostfs-api repository, or update the code to return OK on delete operation if object is already removed.
Steps to Reproduce (for bugs)
Context
This issue affects error checks in S3 gateway when it updates object listing cache after object service operation: TrueCloudLab/frostfs-s3-gw#71
Your Environment
FrostFS DevEnv
Node version:
ed28ce24
@alexvanin, can you clarify how do you invoke removal of the object?
I do like that:
I get the same message:
But
delete
command implicitly invokesHead
remote procedure:ReadOrOpenSession invokes OpenSessionViaClient that invokes collectObjectRelatives that invokes Head
And
Head
has another spec and here is no contradiction.Maybe we should make the error more verbose?
@aarifullin Try to use SDK client to send direct
Delete
request without having extraHead
requests. I getobject already removed
here.The test below creates a SDK client, new FrostFS container, signs and upload the object without payload and then calls delete twice. The second attempt returns 2052 code.
@alexvanin, first of all, thank you for the written unittest :)
Let me omit some details and describe the situtaion briefly:
When client invokes
ObjectDelete
this causes handler invocation from thedeleteSrv
side:object/delete/v2/service.go -> services/object/delete/delete.go -> object/delete/local.go -> formSplitInfo -> ... -> Head
So, again, we send
Head
request to the serivce :)Let's discuss would be it correct to process the error here to support delete spec?
@aarifullin Oh, I get it now, thanks.
Personally I think node should follow a specification there and process
object already removed
error informSpitInfo()
. This function is used only in delete handler, so it should be ok to update it. Something like/cc @TrueCloudLab/storage-core-committers
Okay. I agreed with that and with this PR the status is correct but still as I mentioned here the problem is also with CLI because of the Head request (collectObjectRelatives is within cli and isn't related to splitInfo). Do we agree with this behavior? Or we put the same processing?