Put object should fail when tombstone exists for OID #1512

New issue

Closed

opened 2024-11-20 13:34:32 +00:00 by potyarkin · 2 comments

potyarkin commented

2024-11-20 13:34:32 +00:00

Member

Expected Behavior

After object was deleted while tombstone still exists PUT to the deleted oid should be consistent with subsequent GET/HEAD:

Either all operations should succeed: new object is written and becomes available. This would be my preference but as far as I understand this is quite challenging to implement.
Or all operations should fail: the same error is returned for PUT as for the subsequent GET/HEAD.

Current Behavior

PUT to a deleted object ID appears to be successful. I tested with PutSingle: no errors are returned in (*ResObjectPutSingle).Status() or in error
GET/HEAD after the PUT fails with an expected code = 2052 message = object already removed

Steps to Reproduce (for bugs)

PutSingle(oid)
Delete(oid)
PutSingle(oid): same payload and attrs as before, must result in the same OID
Get(oid)/Head(oid)

Currently step 3 succeeds and step 4 fails. They should either both succeed or both fail.

Context

I was trying to save the same object I've recently deleted. For that object to become readable I had to:

either wait for object.delete.tombstone_lifetime epochs before saving the object for the second time,
or add a meaningless nonce attribute to produce a different oid.

Discussion in private chat.

Regression

No.

Your Environment

Version used: frostfs-node v0.43.2
Server setup and configuration: custom 7-node cluster
Operating System and version (uname -a): Debian 12

## Expected Behavior After object was deleted while tombstone still exists PUT to the deleted oid should be consistent with subsequent GET/HEAD: - Either all operations should succeed: new object is written and becomes available. This would be my preference but as far as I understand this is quite challenging to implement. - Or all operations should fail: the same error is returned for PUT as for the subsequent GET/HEAD. ## Current Behavior - PUT to a deleted object ID appears to be successful. I tested with [PutSingle](https://pkg.go.dev/git.frostfs.info/TrueCloudLab/frostfs-sdk-go/client#Client.ObjectPutSingle): no errors are returned in `(*ResObjectPutSingle).Status()` or in `error` - GET/HEAD after the PUT fails with an expected `code = 2052 message = object already removed` ## Steps to Reproduce (for bugs) 1. PutSingle(oid) 2. Delete(oid) 3. PutSingle(oid): same payload and attrs as before, must result in the same OID 4. Get(oid)/Head(oid) Currently step 3 succeeds and step 4 fails. They should either both succeed or both fail. ## Context I was trying to save the same object I've recently deleted. For that object to become readable I had to: - either wait for `object.delete.tombstone_lifetime` epochs before saving the object for the second time, - or add a meaningless nonce attribute to produce a different oid. Discussion in [private chat](https://chat.yadro.com/yadro/pl/a6b7emyhajbu3reed4r7ta4a5e). ## Regression No. ## Your Environment * Version used: frostfs-node v0.43.2 * Server setup and configuration: custom 7-node cluster * Operating System and version (`uname -a`): Debian 12

potyarkin added the

bug

frostfs-node

triage

labels 2024-11-20 13:34:32 +00:00

aarifullin self-assigned this 2024-11-29 08:00:23 +00:00

fyrchik commented

2024-12-10 12:44:32 +00:00

Owner

PutSingle(oid): same payload and attrs as before, must result in the same OID

We give no guarantees on that the OID will match, e.g. creationEpoch field can differ.
Not to dismiss the issue, but rather to point that reproduction is a bit more tricky.

>3. PutSingle(oid): same payload and attrs as before, must result in the same OID We give no guarantees on that the OID will match, e.g. `creationEpoch` field can differ. Not to dismiss the issue, but rather to point that reproduction is a bit more tricky.

potyarkin commented

2024-12-10 13:57:35 +00:00

Author

Member

Storing an object with the same OID as the one referenced by tombstone is the whole point of this issue. That's why I highlighted it in "Steps to Reproduce" - only matching OIDs will trigger the bug.

aarifullin referenced this issue from a pull request that will close it,

2024-12-23 12:03:08 +00:00

Fix PutSingle with OID that was already removed #1579