Skip to content
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

Drop ResolveNeoFSFailures #413

Merged
merged 12 commits into from
May 19, 2023
Merged

Conversation

smallhive
Copy link
Contributor

@smallhive smallhive commented May 15, 2023

close #406
fixes #405

@smallhive smallhive force-pushed the 406-drop-resolveneofsfailures branch 3 times, most recently from 890364b to 9cba1b6 Compare May 16, 2023 10:41
@smallhive
Copy link
Contributor Author

@roman-khimov @cthulhu-rider @notimetoname

I want to attract your attention to one question. I'm almost done the PR, but it perfectly works only for Go1.20.
Go < 1.20 doesn't have some functions in errors package. That is why I have to make this commit to fix this.

Be honest, I'm completely not exiting about it, because we should revert/update it in future. When minimal Go version will be 1.20 it should be replaced with errors.Join here like errors.Join(ErrAPI, err)

I tend to think, I'm missing some good solution to wrap multiple errors (and correct check them with errors.Is) in Go < 1.20. May be you may suggest something about that.

How I understand setting Go 1.20 as minimum version in SDK is not an option, right?

@roman-khimov
Copy link
Member

How I understand setting Go 1.20 as minimum version in SDK is not an option, right?

Yes, we can't demand it for any of our components, but especially in SDK, it can be used by random people and we can't expect them to have 1.20. So we absolutely need this compatibility code that will eventually be taken out.

@notimetoname
Copy link
Contributor

notimetoname commented May 16, 2023

How I understand setting Go 1.20 as minimum version in SDK is not an option, right?

Sweet dreams but dont think so.

I'm completely not exiting about it

Me too. The only thing i would request is to leave as many reminders to fix it when 1.22 is out as possible (comments, issues, links/TODOs/etc).

@smallhive
Copy link
Contributor Author

The only thing i would request is to leave as many reminders to fix it when 1.23 is out as possible (comments, issues, links/TODOs/etc).

Agree, I will add them when we decide what and how we manage to this.

@roman-khimov
Copy link
Member

We just need an issue to track this. And we better keep commits the way they are (using new APIs and then changing to old ones), it'd be trivial to revert then.

@smallhive
Copy link
Contributor Author

We just need an issue to track this. And we better keep commits the way they are (using new APIs and then changing to old ones), it'd be trivial to revert then.

Sure, I will make it

@smallhive smallhive force-pushed the 406-drop-resolveneofsfailures branch from 9cba1b6 to ed1ff35 Compare May 16, 2023 11:45
@smallhive smallhive marked this pull request as ready for review May 16, 2023 11:49
Copy link
Member

@roman-khimov roman-khimov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now consider some ResObjectDelete, why does it have a statusRes inside when it's no longer being used? It can't have anything but successful value, because all the other codes are returned as errors. Then consider something like ResContainerDelete, is it needed at all with the new scheme? Let's simplify these things as well.

client/status/common.go Outdated Show resolved Hide resolved
client/container.go Outdated Show resolved Hide resolved
storagegroup/storagegroup_test.go Outdated Show resolved Hide resolved
@cthulhu-rider
Copy link
Contributor

i only had time to briefly review the proposed changes

i think apistatus package shouldn't be touched at all because it declares structured errors and that's clean. I'd leave this package passive and implement all business logic in client package - it actively returns errors (but not only, for example, storage node does not need all this functionality with wrapping errors in so-called API ones at all). client package has everything he needs to work with API errors (all types provide error, apistatus.Status, As(any) bool and Is(error) bool interfaces)

@roman-khimov
Copy link
Member

i think apistatus package shouldn't be touched at all

We need some type for generic API error and as we have (almost) all of them in apistatus, it makes sense to continue using it. Otherwise we better move all of errors into client, which is an option, but a bit more invasive one. I'd stick to apistatus for now.

@cthulhu-rider
Copy link
Contributor

Otherwise we better move all of errors into client, which is an option

not a good option to me: apistatus is also used by server side (that's why it was designed as an autonomous package). At the same time, error classification (internal, API or low-level) applies only to the client side. That's why I suggest such packaging

@roman-khimov
Copy link
Member

apistatus obviously only contains NeoFS protocol errors, it's OK for it to provide some means for checking for any or a group of these errors. It can be used by any side then without any issues.

@cthulhu-rider
Copy link
Contributor

cthulhu-rider commented May 16, 2023

it's OK for it to provide some means for checking for any

yes, it does, there is https://pkg.go.dev/github.com/nspcc-dev/neofs-sdk-go@v1.0.0-rc.8/client/status#Status interface provided by all protocol statuses incl. errors (although empty now, but can be extended). That's enough for any party. Network errors occur in client games only

i don't mind to have API error group in apistatus package, as for me it does not matter, although it is at odds with my vision of organizing packages

@smallhive smallhive force-pushed the 406-drop-resolveneofsfailures branch from ed1ff35 to c14dc05 Compare May 17, 2023 07:24
@smallhive smallhive force-pushed the 406-drop-resolveneofsfailures branch from c14dc05 to 4ef4ffe Compare May 17, 2023 08:32
Copy link
Member

@roman-khimov roman-khimov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #413 (review) as well.

client/status/unrecognized.go Show resolved Hide resolved
client/status/unrecognized.go Show resolved Hide resolved
client/errors_test.go Show resolved Hide resolved
client/status/status.go Outdated Show resolved Hide resolved
client/status/v2_test.go Outdated Show resolved Hide resolved
client/netmap.go Outdated Show resolved Hide resolved
client/netmap.go Outdated Show resolved Hide resolved
client/object_delete.go Show resolved Hide resolved
client/object_get.go Show resolved Hide resolved
client/object_hash.go Show resolved Hide resolved
@smallhive smallhive force-pushed the 406-drop-resolveneofsfailures branch 2 times, most recently from d876fb2 to 516df0a Compare May 17, 2023 09:52
@smallhive smallhive force-pushed the 406-drop-resolveneofsfailures branch from 516df0a to ed1536f Compare May 17, 2023 10:37
client/status/status.go Outdated Show resolved Hide resolved
client/status/common.go Outdated Show resolved Hide resolved
client/container.go Outdated Show resolved Hide resolved
client/container.go Outdated Show resolved Hide resolved
client/netmap_test.go Outdated Show resolved Hide resolved
client/object_get.go Show resolved Hide resolved
client/object_get.go Show resolved Hide resolved
client/object_search.go Outdated Show resolved Hide resolved
client/object_search.go Outdated Show resolved Hide resolved
pool/pool.go Outdated Show resolved Hide resolved
@smallhive smallhive force-pushed the 406-drop-resolveneofsfailures branch 4 times, most recently from 67af63a to e07c8fb Compare May 19, 2023 06:14
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
TestFromStatusV2 and TestToStatusV2 have the identical testcases and code to check them

Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
@smallhive smallhive force-pushed the 406-drop-resolveneofsfailures branch from e07c8fb to 95ecf9f Compare May 19, 2023 06:33
Copy link
Member

@roman-khimov roman-khimov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+583 −817 --- looks better now
Please mention #405 in commits/PR, because this patch set fixes it as well.

Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Should be reverted/updated when minimum version of Go will be set to 1.20

Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Fixes #405

Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
Signed-off-by: Evgenii Baidakov <evgenii@nspcc.io>
@smallhive smallhive force-pushed the 406-drop-resolveneofsfailures branch from a91a957 to 49bc3b7 Compare May 19, 2023 08:25
@roman-khimov roman-khimov merged commit cfdd870 into master May 19, 2023
@roman-khimov roman-khimov deleted the 406-drop-resolveneofsfailures branch May 19, 2023 09:13
roman-khimov added a commit that referenced this pull request May 29, 2023
We've got a number of `Res*` things with a single member only. They were
somewhat useful before #413 (to get request status), but now they
provide zero value and just complicate the code using these APIs. Notice
also that this makes `client` interface a little close to `pool`
interface which is nice wrt. #380.
carpawell added a commit to nspcc-dev/neofs-node that referenced this pull request Oct 1, 2024
It is possible and safe after nspcc-dev/neofs-sdk-go#413.

Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Drop ResolveNeoFSFailures Make ObjectReader/ObjectRangeReader compatible with io.Closer/io.ReaderCloser
4 participants