object-lock command improvement suggestions #840

New issue

Open

opened 2025-12-28 17:20:51 +00:00 by sami · 3 comments

sami commented

2025-12-28 17:20:51 +00:00

Owner

Originally created by @vkarak1 on GitHub (Oct 25, 2022).

Could you please consider two suggestions to the object-lock command:

Object lock can not be run while shard is in read-only state and neofs-cli returns unfriendly message, is that possible to improve the message in described case? Now it displays:
Store lock object in NeoFS: client failure: status: code = 1024 message = lock operation failed
It would be great to specify object_id and container_id in object-lock command using usual "--cid" and "--oid" prefixes. Now the command looks the following:
neofs-cli object lock -r node1:8080 -w /etc/neofs/storage/wallet.json --expire-at 10 893dGYPLgRNSiqVBW61J7aP1xLvsYzGxQViNZ6smmUx5 8sRdhwH6ERxjC4cpXEiNcVYaeYudGynpzxsD6wfCJSGk

NeoFS Storage node
Version: v0.33.0-31-ge1be0180
GoVersion: go1.18.4

Originally created by @vkarak1 on GitHub (Oct 25, 2022). ## Is your feature request related to a problem? Please describe. Could you please consider two suggestions to the object-lock command: 1. Object lock can not be run while shard is in read-only state and neofs-cli returns unfriendly message, is that possible to improve the message in described case? Now it displays: `Store lock object in NeoFS: client failure: status: code = 1024 message = lock operation failed` 2. It would be great to specify object_id and container_id in object-lock command using usual "--cid" and "--oid" prefixes. Now the command looks the following: ` neofs-cli object lock -r node1:8080 -w /etc/neofs/storage/wallet.json --expire-at 10 893dGYPLgRNSiqVBW61J7aP1xLvsYzGxQViNZ6smmUx5 8sRdhwH6ERxjC4cpXEiNcVYaeYudGynpzxsD6wfCJSGk` NeoFS Storage node Version: v0.33.0-31-ge1be0180 GoVersion: go1.18.4

sami added the

enhancement

neofs-storage

discussion

labels

2025-12-28 17:20:51 +00:00

sami commented

2025-12-28 17:20:51 +00:00

Author

Owner

@carpawell commented on GitHub (Nov 14, 2022):

@cthulhu-rider, @fyrchik, @realloc, 1. took another form after the fix. Is it the expected kind of that error representation (forwarding, wrapping and all)?

2. Was fixed via the #1998.

@carpawell commented on GitHub (Nov 14, 2022): @cthulhu-rider, @fyrchik, @realloc, `1.` took another [form](https://github.com/nspcc-dev/neofs-node/pull/2008#issuecomment-1299938367) after the fix. Is it the expected kind of that error representation (forwarding, wrapping and all)? `2.` Was fixed via the #1998.

sami commented

2025-12-28 17:20:51 +00:00

Author

Owner

@carpawell commented on GitHub (Nov 30, 2022):

Closed via #1998.

@carpawell commented on GitHub (Nov 30, 2022): Closed via #1998.

sami commented

2025-12-28 17:20:51 +00:00

Author

Owner

@carpawell commented on GitHub (Dec 12, 2022):

I misunderstand the 1. point, it is about an error description, not about an error chain.

The problem is in that line: we just do not have enough information about the errors we get. I guess it was done on purpose: we iterate over some shard set and we do not have any error that could wrap some other errors, so it is just not clear what error we can return here: the first, the last of try to add some API error that could wrap all errors from all shards and return that "encapsulated error set".

The case that led to that error creation was RO mode for every node's shard. So what message could be printed here? RO shard? That would mean that the last shard failed because of RO but no info about the previous ones. What if the first one (the desired one) has RO mode? print nothing cause that is not an error and we did lock an object?

/cc @fyrchik, @vkarak1, @acid-ant, @cthulhu-rider

@carpawell commented on GitHub (Dec 12, 2022): I misunderstand the `1.` point, it is about an error description, not about an error chain. The problem is in [that](https://github.com/nspcc-dev/neofs-node/blob/b122312e4b0f03c443b12378027fb7f1f27fd69b/pkg/local_object_storage/engine/lock.go#L50) line: we just do not have enough information about the errors we get. I guess it was done on purpose: we iterate over _some shard set_ and we do not have any error that could wrap some other errors, so it is just not clear what error we can return here: the first, the last of try to add some API error that could wrap all errors from all shards and return that "encapsulated error set". The case that led to that error creation was RO mode for every node's shard. So what message could be printed here? RO shard? That would mean that the last shard failed because of RO but no info about the previous ones. What if the first one (the desired one) has RO mode? print nothing cause that is not an error and we _did_ lock an object? /cc @fyrchik, @vkarak1, @acid-ant, @cthulhu-rider