-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible incorrect error when a container is deleted by a static session token without the right permissions #2466
Comments
expected behavior is described in nspcc-dev/neofs-testcases#579, so any other behaviors are incorrect (bug) |
Yes, but there's no description of expected errors |
|
@cthulhu-rider What is this new error message?
|
It's the same thing (see #2501 as well). |
If container session token is incorrect, there is no need in Alphabet's check, the error can be returned immediately to a client; otherwise he has to wait for the TX to persist infinitely with not feedback. Closes #2466. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
If container session token is incorrect, there is no need in Alphabet's check, the error can be returned immediately to a client; otherwise he has to wait for the TX to persist infinitely with not feedback. Closes #2466. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
If container session token is incorrect, there is no need in Alphabet's check, the error can be returned immediately to a client; otherwise he has to wait for the TX to persist infinitely with not feedback. Closes #2466. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
If container session token is incorrect, there is no need in Alphabet's check, the error can be returned immediately to a client; otherwise he has to wait for the TX to persist infinitely with not feedback. Closes #2466. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
If container session token is incorrect, there is no need in Alphabet's check, the error can be returned immediately to a client; otherwise he has to wait for the TX to persist infinitely with not feedback. Closes #2466. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
If container session token is incorrect, there is no need in Alphabet's check, the error can be returned immediately to a client; otherwise he has to wait for the TX to persist infinitely with not feedback. Closes #2466. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
If container session token is incorrect, there is no need in Alphabet's check, the error can be returned immediately to a client; otherwise he has to wait for the TX to persist infinitely with not feedback. Closes #2466. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
I write tests on the issue nspcc-dev/neofs-testcases#579
and I found that neofs-cli container delete handle differently in the negative case when a non-valid wallet is specified.
The difference is which static session token I use - the one created on the container owner's wallet, or the one created on another wallet.
Expected Behavior
I'm not sure it's exactly a bug, I'd like to discuss what behavior we expect in which case.
Steps to Reproduce (for bugs)
See allure reports:
report.zip
report_2.zip
Test code:
Your Environment
neo-go
0.101.1
neofs-s3-authmate
0.27.1
neofs-cli
0.36.1-125-g8cda197e
neofs-adm
0.36.1-125-g8cda197e
AWS
aws-cli/2.9.19 Python/3.11.4 Linux/6.2.0-25-generic source/x86_64.ubuntu.23 prompt/off
The text was updated successfully, but these errors were encountered: