I'm able to find the object that is marked for deletion about neofs-node HOT 8 CLOSED

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.

from neofs-node.

an appropriate error code should be returned from neofs-cli

Next available for now (3)?

from neofs-node.

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

from neofs-node.

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.

from neofs-node.

Can be checked for the mainnet 2uvJyFRpcw6tKXSyypa2LSGLuF4qavL34GiutpjojkBZ container.

from neofs-node.

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.

from neofs-node.

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.

from neofs-node.

Considering this as fixed until proven otherwise.

from neofs-node.