Support InvalidArgument common failure status #277

Merged
fyrchik merged 4 commits from a-savchuk/frostfs-sdk-go:invalid-argument-status into master 2024-11-02 14:21:46 +00:00
Member

Close #274

Signed-off-by: Aleksey Savchuk a.savchuk@yadro.com

Close #274 Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
a-savchuk added 4 commits 2024-10-02 08:23:07 +00:00
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
[#274] client/status: Add missing test cases for commom statuses
All checks were successful
DCO / DCO (pull_request) Successful in 59s
Tests and linters / Tests (pull_request) Successful in 1m7s
Tests and linters / Lint (pull_request) Successful in 2m4s
01abee9c64
Signed-off-by: Aleksey Savchuk <a.savchuk@yadro.com>
a-savchuk changed title from WIP: Support InvalidArgument common failure status to Support InvalidArgument common failure status 2024-10-02 08:25:26 +00:00
a-savchuk changed title from Support InvalidArgument common failure status to WIP: Support InvalidArgument common failure status 2024-10-02 08:25:30 +00:00
a-savchuk changed title from WIP: Support InvalidArgument common failure status to Support InvalidArgument common failure status 2024-10-02 08:25:31 +00:00
a-savchuk requested review from storage-core-developers 2024-10-02 08:25:50 +00:00
a-savchuk requested review from storage-core-committers 2024-10-02 08:25:51 +00:00
a-savchuk requested review from storage-services-developers 2024-10-02 08:25:52 +00:00
a-savchuk requested review from storage-services-committers 2024-10-02 08:25:53 +00:00
fyrchik requested changes 2024-10-02 12:22:33 +00:00
@ -115,3 +115,3 @@
stV2 := st.ToStatusV2()
require.Empty(t, "", stV2.Message())
require.Equal(t, "node is under maintenance", stV2.Message())
Owner

How did it pass earlier?

How did it pass earlier?
Author
Member

require.Empty checks that "" is empty and it's empty indeed, so the test has succeeded. st2.Message() was mistakenly passed as an info message to display if the test had failed.

`require.Empty` checks that `""` is empty and it's empty indeed, so the test has succeeded. `st2.Message()` was mistakenly passed as an info message to display if the test had failed.
Owner

Indeed, I have written this code, seems to be copy-paste error.

Indeed, I have written this code, seems to be copy-paste error.
fyrchik marked this conversation as resolved
@ -649,14 +649,14 @@ func TestHandleError(t *testing.T) {
},
{
ctx: ctx,
status: new(apistatus.SignatureVerification),
Owner

Why do you change unrelated tests instead of adding new ones?

Why do you change unrelated tests instead of adding new ones?
Author
Member

There were two duplicate test cases:

Lines 643 to 656 in 1b67ab9
{
ctx: ctx,
status: new(apistatus.SignatureVerification),
err: nil,
expectedError: true,
countError: true,
},
{
ctx: ctx,
status: new(apistatus.SignatureVerification),
err: nil,
expectedError: true,
countError: true,
},

I've deleted one of them and added a new one for the new status, but Git shows it as if I changed the existing test. Should I keep the duplicate test case?

There were two duplicate test cases: https://git.frostfs.info/TrueCloudLab/frostfs-sdk-go/src/commit/1b67ab9608482f2f862fb582cd2570949ef83528/pool/pool_test.go#L643-L656 I've deleted one of them and added a new one for the new status, but Git shows it as if I changed the existing test. Should I keep the duplicate test case?
fyrchik marked this conversation as resolved
acid-ant approved these changes 2024-10-02 12:50:04 +00:00
Dismissed
dkirillov reviewed 2024-10-02 13:42:13 +00:00
pool/pool.go Outdated
@ -1228,2 +1228,3 @@
*apistatus.SignatureVerification,
*apistatus.NodeUnderMaintenance:
*apistatus.NodeUnderMaintenance,
*apistatus.InvalidArgument:
Member

I'm not sure if we should count such error. It's more like access denied the node is working but user provide some incorrect data

I'm not sure if we should count such error. It's more like `access denied` the node is working but user provide some incorrect data
Owner

To me, it looks similar to SignatureVerification, because in both cases I have provided an incorrect request. So current placement seems valid.

To me, it looks similar to `SignatureVerification`, because in both cases I have provided an incorrect request. So current placement seems valid.
Author
Member

As for me, it looks a bit controversial that we count each of so called 'common failures' except that one. I'm clueless. So what's the final decision?

As for me, it looks a bit controversial that we count each of so called 'common failures' except that one. I'm clueless. So what's the final decision?
Owner

The difference with SignatureVerification for me is that SDK Client user cannot fix this error: it is returned when storage node and client work with incompatible API versions. So it is okay to increment error counter and switch endpoint eventually.

InvalidArgument on the other hand, can be fixed by SDK Client user by changing request parameters. @a-savchuk can you double check this? If it is incorrect, then let's keep it as it is.

The difference with `SignatureVerification` for me is that SDK Client user **cannot** fix this error: it is returned when storage node and client work with incompatible API versions. So it is okay to increment error counter and switch endpoint eventually. `InvalidArgument` on the other hand, **can** be fixed by SDK Client user by changing request parameters. @a-savchuk can you double check this? If it is incorrect, then let's keep it as it is.
Owner

True, but why would we deliberately send invalid request in the first place? Most likely it is related to some version incompatibility too, and I doubt we can handle such errors automatically.

True, but why would we deliberately send invalid request in the first place? Most likely it is related to some version incompatibility too, and I doubt we can handle such errors automatically.
Owner

Anyway, I am OK with both options.

Anyway, I am OK with both options.
Owner

Most likely it is related to some version incompatibility too, and I doubt we can handle such errors automatically.

That's good point. Maybe I lack some context when InvalidArgument is returned.

If this error returns when client structures are incompatible, then it makes sense to count this error.

If it also returns on invalid user input, then do not count this error.

> Most likely it is related to some version incompatibility too, and I doubt we can handle such errors automatically. That's good point. Maybe I lack some context when `InvalidArgument` is returned. If this error returns when client structures are incompatible, then it makes sense to count this error. If it also returns on invalid _user_ input, then do not count this error.
Owner

We curently cannot distinguish between these 2 options, so yes, let's not count.

We curently cannot distinguish between these 2 options, so yes, let's not count.
Author
Member

All done

All done
a-savchuk force-pushed invalid-argument-status from 01abee9c64 to 997346ef95 2024-10-03 14:06:02 +00:00 Compare
a-savchuk dismissed acid-ant's review 2024-10-03 14:06:03 +00:00
Reason:

New commits pushed, approval review dismissed automatically according to repository settings

acid-ant approved these changes 2024-10-03 17:50:43 +00:00
dkirillov approved these changes 2024-10-04 08:07:31 +00:00
fyrchik merged commit 997346ef95 into master 2024-10-04 09:17:57 +00:00
Sign in to join this conversation.
No reviewers
TrueCloudLab/storage-core-developers
TrueCloudLab/storage-services-developers
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-sdk-go#277
No description provided.