Tombstone classified as root object

[alexvanin]

Object search with --root flag in CLI returns tombstone object ID but it shouldn't.

Steps to Reproduce

1. Upload non-split object
2. Remove non-split object
3. Wait for garbage collector to remove original object
4. Search in container for root objects.

Your Environment

• Version used: 0.12.0-rc3-22-g54818d5

[cthulhu-rider]

Well, physically tombstones are root objects. Is there a requirement to exclude tombstones from such a search?

[alexvanin]

Well, physically tombstones are root objects. Is there a requirement to exclude tombstones from such a search?

Yes, in nspcc-dev/neofs-api-go#163 we discussed leaf and root objects as a system and user scope. Tombstone is an internal implementation detail and should not be seen in user scope, therefore tombstone is not a root object. However it is a physically stored object, that can be migrated and replicated, so it is a leaf.

[cthulhu-rider]

Well, physically tombstones are root objects. Is there a requirement to exclude tombstones from such a search?

Yes, in nspcc-dev/neofs-api-go#163 we discussed leaf and root objects as a system and user scope. Tombstone is an internal implementation detail and should not be seen in user scope, therefore tombstone is not a root object. However it is a physically stored object, that can be migrated and replicated, so it is a leaf.

According to neofs-api tombstones match root filter. Is it a bug in API?

[alexvanin]

According to neofs-api tombstones match root filter. Is it a bug in API?

I would like to say yes, but maybe there are different opinions on that. Neofs-api contains implementation details, but it lacks the meaning behind root and leaf objects (as for me, they should represent user and system scopes)

[cthulhu-rider]

What do you think @realloc?

[realloc]

I think Tombstones are a special type of objects, as indicated in ObjectType. Object Search operations should work with Regular objects by default. If there is need to search for Tombstones or Storage Groups, the one may use $Object:objectType key.

Tombstone has a list of engraved objects in it's payload, just like Storage Group does. It doesn't participate in split hierarchy directly, it doesn't have split headers and because of that it should not be treated as leaf or root object. I propose to exclude Tombstones and Storage Groups from regular search and reflect that behaviour in documentation.

[alexvanin]

I think Tombstones are a special type of objects, as indicated in ObjectType. Object Search operations should work with Regular objects by default. If there is need to search for Tombstones or Storage Groups, the one may use $Object:objectType key.

Tombstone has a list of engraved objects in it's payload, just like Storage Group does. It doesn't participate in split hierarchy directly, it doesn't have split headers and because of that it should not be treated as leaf or root object. I propose to exclude Tombstones and Storage Groups from regular search and reflect that behaviour in documentation.

While I agree that only regular objects should be treated as root object, I cannot agree about leafs. Leafs are designed to return physically stored object. It is useful for system operations like replication because storage groups, tombstone and regular objects should be treated equally.

[realloc]

I propose to implicitly add $Object:objectType=REGULAR to $Object:ROOT filter then and reflect it in api doc and leave other filters as-is.