[#131] client: Switch ResolveFrostFSFailures to DisableFrostFSFailuresResolution option #163
No reviewers
TrueCloudLab/storage-core-developers
TrueCloudLab/storage-services-committers
TrueCloudLab/storage-services-developers
Labels
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
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-sdk-go#163
Loading…
Reference in a new issue
No description provided.
Delete branch "olefirenque/frostfs-sdk-go:131-refactor_frostfs_failure_resolving_option"
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?
Changed
client.PrmInit.ResolveFrostFSFailures
name and semantics to the opposite@ -145,3 +145,3 @@
// See also Init.
type PrmInit struct {
resolveFrostFSErrors bool
dontResolveFrostFSErrors bool
Let's discuss:
I am not so picky about names but I would not consider the "dont" prefix for a boolean variable name.
What do you think about
disableFrostFSErrorResolution
?fair enough
@ -67,3 +67,1 @@
// If PrmInit.ResolveFrostFSFailures has been called, unsuccessful
// FrostFS status codes are returned as `error`, otherwise, are included
// in the returned result structure.
// If PrmInit.DontResolveFrostFSFailures has been called, unsuccessful
It seems
PrmInit.ResolveFrostFSFailures
was not correct because it referred to the inactual name.For now it should be
PrmInit.dontResolveFrostFSErrors
PrmInit.ResolveFrostFSFailures
referred to the function name that is used to set the value ofPrmInit.resolveFrostFSErrors
field. But maybe it's better to unify the field name and the function name?Okay. That's fine then. No need to unify names :)
WIP: [#131] client: Switch ResolveFrostFSFailures to DontResolveFrostFSFailures optionto [#131] client: Switch ResolveFrostFSFailures to DontResolveFrostFSFailures optionc133e20009
to15bdb42d73
15bdb42d73
to9d1375b453
[#131] client: Switch ResolveFrostFSFailures to DontResolveFrostFSFailures optionto WIP: [#131] client: Switch ResolveFrostFSFailures to DontResolveFrostFSFailures option9d1375b453
tod241aa92bf
WIP: [#131] client: Switch ResolveFrostFSFailures to DontResolveFrostFSFailures optionto [#131] client: Switch ResolveFrostFSFailures to DontResolveFrostFSFailures optionGood job!
@ -43,3 +43,3 @@
var prmInit client.PrmInit
prmInit.SetDefaultPrivateKey(key) // private key for request signing
prmInit.ResolveFrostFSFailures() // enable erroneous status parsing
prmInit.DisableFrostFSFailuresResolution() // disable erroneous status parsing
Can we just remove this line from doc? We would like to get rid of this in future and
ResolveFrostFSFAilures
is now a default behaviour, which everyone should use.@ -170,0 +165,4 @@
// FrostFS protocol only in resulting structure (see corresponding Res* docs).
// These errors are returned from each protocol operation. By default, statuses
// are resolved and returned as a Go built-in errors.
func (x *PrmInit) DisableFrostFSFailuresResolution() {
This will break lots of client code, can we leave this method, mark it as
Deprecated
and add a new one?PrmInit.ResolveFrostFSFailures()
must be aDeprecated
one without any effects andPrmInit.DisableFrostFSFailuresResolution()
is a new one, right?@ -84,6 +84,7 @@ func TestClient_NetMapSnapshot(t *testing.T) {
srv.signResponse = true
// status failure
c.prm.DisableFrostFSFailuresResolution()
It is better to do this near the client initialization at line 69. This way all statements in test will use the same logic (as it was before this PR).
[#131] client: Switch ResolveFrostFSFailures to DontResolveFrostFSFailures optionto [#131] client: Switch ResolveFrostFSFailures to DisableFrostFSFailuresResolution optionResolveFrostFSFailures
the default option. #131