TrueCloudLab/frostfs-sdk-go
30
0
Fork 21
Code Issues 30 Pull requests 3 Releases Activity Actions

Support InvalidArgument common failure status #277

Merged
fyrchik merged 1 commit from a-savchuk/frostfs-sdk-go:invalid-argument-status into master 2024-11-02 14:21:46 +00:00
Conversation 0 Commits 1 Files changed 1 +18 -12
a-savchuk commented 2024-10-02 08:23:06 +00:00
Member
Copy link

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
Details
Tests and linters / Tests (pull_request) Successful in 1m7s
Details
Tests and linters / Lint (pull_request) Successful in 2m4s
Details
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
client/status/common_test.go Outdated
@ -115,3 +115,3 @@
stV2 := st.ToStatusV2()
require.Empty(t, "", stV2.Message())
require.Equal(t, "node is under maintenance", stV2.Message())
fyrchik commented 2024-10-02 12:21:26 +00:00
Owner
Copy link

How did it pass earlier?

How did it pass earlier?
a-savchuk commented 2024-10-02 12:39:04 +00:00
Author
Member
Copy link

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.
fyrchik commented 2024-10-03 06:56:17 +00:00
Owner
Copy link

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
pool/pool_test.go Outdated
@ -649,14 +649,14 @@ func TestHandleError(t *testing.T) {
},
{
ctx: ctx,
status: new(apistatus.SignatureVerification),
fyrchik commented 2024-10-02 12:22:06 +00:00
Owner
Copy link

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

Why do you change unrelated tests instead of adding new ones?
a-savchuk commented 2024-10-02 12:43:35 +00:00
Author
Member
Copy link

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:
dkirillov commented 2024-10-02 13:42:13 +00:00
Member
Copy link

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
👀 1
fyrchik commented 2024-10-03 06:57:30 +00:00
Owner
Copy link

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.
👀 2
a-savchuk commented 2024-10-03 08:07:55 +00:00
Author
Member
Copy link

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?
alexvanin commented 2024-10-03 11:57:27 +00:00
Owner
Copy link

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.
fyrchik commented 2024-10-03 12:12:56 +00:00
Owner
Copy link

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.
fyrchik commented 2024-10-03 12:13:09 +00:00
Owner
Copy link

Anyway, I am OK with both options.

Anyway, I am OK with both options.
alexvanin commented 2024-10-03 12:21:53 +00:00
Owner
Copy link

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.
👍 3
fyrchik commented 2024-10-03 13:20:25 +00:00
Owner
Copy link

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.
a-savchuk commented 2024-10-03 14:08:01 +00:00
Author
Member
Copy link

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.
Reviewers
No reviewers
fyrchik
acid-ant
dkirillov
TrueCloudLab/storage-core-developers
TrueCloudLab/storage-services-developers
Labels
Clear labels   
P0

Highest

  
P1

High

  
P2

Medium

  
P3

Low

  
good first issue

Good for newcomers

  
pool

Tasks related to client pool

  
Infrastructure

Infrastructure, Automation, CI/CD or DevOps related stuff

  
blocked

The issue or PR is blocked by something

  
bug

Something is not working

  
config

Configuration format update or breaking change

  
discussion

Talking about something in order to reach a decision or to exchange ideas

  
documentation

Documentation related

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
go

Language features adoption

  
help wanted

Extra attention is needed

  
internal

   
invalid

Something is wrong

  
kludge

This is a kludge and we know it

  
observability

Related to metrics, tracing and logs

  
perfomance

Perfomance related

  
question

More information is needed

  
refactoring

Refactoring

  
wontfix

This won't be fixed

No labels
P0
P1
P2
P3
good first issue
pool
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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.
Delete branch "a-savchuk/frostfs-sdk-go:invalid-argument-status"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?