I'm able to find the object that is marked for deletion

[aprasolova]

In testnet, I search for an object by FilePath attribute in the container ApUZhHKta4pikXAtvJR2sBQ3TikKErywCCdQQKgWAgvp. I find the object 9DRzt8EBLeoueo6axHr58sYj6V4a5BLXSQ7jSwNAo1gf . Then I try to delete it and get error code = 2052 message = object already removed. I guess it happens because the object is marked for deletion.

Expected Behaviour

If object is marked for deletion, it doesn't appear as a search result.

Current Behavior

It does

[roman-khimov]

1. In general, until we have some synchronized metadata it's OK. One node may have a tombstone object, another one may not.
2. Still, if a node has both an object and a tombstone for it, it MUST NOT include it into the result, this needs to be checked.
3. Script should handle this error, an appropriate error code should be returned from neofs-cli and checked for by the script.

[notimetoname]

an appropriate error code should be returned from neofs-cli

Next available for now (3)?

[vvarg229]

We have a falling system test test_object2_can_be_get_by_attr https://github.com/nspcc-dev/neofs-testcases/blob/master/pytest_tests/testsuites/services/http_gate/test_http_headers.py#L110

We delete an object and expect an "object already removed" error to be returned when we try to get it after the deletion. Right now it works so that we get "404 not found".

Is this expected behavior correct?

allure report:
dddd.zip

[roman-khimov]

That's nspcc-dev/neofs-http-gw@e6e7941 and that's correct, the object can no longer be found. Previously it was "Bad Request" returned from the HTTP gate and that wasn't correct, the request is perfectly fine here.

[roman-khimov]

Can be checked for the mainnet 2uvJyFRpcw6tKXSyypa2LSGLuF4qavL34GiutpjojkBZ container.

[carpawell]

I have been looking at that bug for a while but have not found any problems. I tested mentioned contianers, look at the code but seems like it is impossible (or I need to look at this in some removal process or at the script). Added a separate code in #2526.

I guess, script may do some things fast while TS objects have not been replicated yet.

[roman-khimov]

The way the script worked at the time of writing is:

• iterate over uploaded files, see some img/cat.png
• SEARCH for img/cat.png
• DELETE that object(s)
• PUT new object for img/cat.png

IIRC the problem happened when someone tried to run the script several times in a row before objects are really deleted. So it's certainly not some ms-range problem.

[roman-khimov]

Considering this as fixed until proven otherwise.