[SUPPORT]: Ignore ECInfoErr erros in GetSplitInfo #313

aarifullin · 2024-12-11T15:27:20Z

aarifullin commented

2024-12-11 15:27:20 +00:00

Ignore ECInfoError errors after raw HeadObject request in GetSplitInfo

Close #312

* Ignore `ECInfoError` errors after raw `HeadObject` request in `GetSplitInfo` Close #312

aarifullin added the

pool

label 2024-12-11 15:27:20 +00:00

aarifullin added 1 commit 2024-12-11 15:27:21 +00:00

[#312 ] pool: Ignore ECInfoErr erros in GetSplitInfo

DCO / DCO (pull_request) Successful in 1m47s

Details

Tests and linters / Tests (pull_request) Successful in 2m1s

Details

Tests and linters / Lint (pull_request) Successful in 2m44s

Details

015f6e3891

* Ignore `ECInfoError` errors after raw `HeadObject` request

Signed-off-by: Airat Arifullin <a.arifullin@yadro.com>

aarifullin added the

bug

label 2024-12-11 15:27:30 +00:00

aarifullin changed title from ~~Ignore ECInfoErr erros in GetSplitInfo~~ to SUPPORT: Ignore ECInfoErr erros in GetSplitInfo

2024-12-11 15:27:36 +00:00

aarifullin changed title from ~~SUPPORT: Ignore ECInfoErr erros in GetSplitInfo~~ to [SUPPORT]: Ignore ECInfoErr erros in GetSplitInfo

2024-12-11 15:27:49 +00:00

aarifullin requested review from storage-core-committers 2024-12-11 15:28:00 +00:00

aarifullin requested review from storage-core-developers 2024-12-11 15:28:02 +00:00

aarifullin requested review from storage-services-committers 2024-12-11 15:28:18 +00:00

aarifullin requested review from storage-services-developers 2024-12-11 15:28:19 +00:00

alexvanin approved these changes 2024-12-11 15:49:50 +00:00

elebedeva approved these changes 2024-12-11 16:01:10 +00:00

pool/pool.go

					
				@ -2990,3 +2991,3 @@

					case errors.As(err, &errSplit):

						return errSplit.SplitInfo(), nil

					case err == nil:

					case err == nil || errors.As(err, &errECInfo):

elebedeva commented

2024-12-11 16:00:37 +00:00

Why using errors.As() here and not errors.Is()?

Why using `errors.As()` here and not `errors.Is()`?

alexvanin commented

2024-12-12 06:32:47 +00:00

errors.Is checks exact error value (similar to == check) while errors.As tries to cast error to error type.

Exact value check is being used when error is explicitly defined (e.g. MyError := errors.New("my error").

returnedError := object.NewECInfoError(&object.ECInfo{
	Chunks: []v2object.ECChunk{{Index: 1, Total: 2}},
})

// Try to check error
var errECInfo *object.ECInfoError
fmt.Println(errors.Is(returnedError, errECInfo))  // false
fmt.Println(errors.As(returnedError, &errECInfo)) // true

`errors.Is` checks exact error value (similar to `==` check) while `errors.As` tries to cast error to error type. Exact value check is being used when error is explicitly defined (e.g. `MyError := errors.New("my error"`). ```go returnedError := object.NewECInfoError(&object.ECInfo{ Chunks: []v2object.ECChunk{{Index: 1, Total: 2}}, }) // Try to check error var errECInfo *object.ECInfoError fmt.Println(errors.Is(returnedError, errECInfo)) // false fmt.Println(errors.As(returnedError, &errECInfo)) // true ```

aarifullin commented

2024-12-12 07:06:29 +00:00

@alexvanin is right.
errors.Is would have been used if var errECInfo = errors.New("object not found, ec info provided"), but it's introduced as complex type with data within

@alexvanin is right. `errors.Is` would have been used if `var errECInfo = errors.New("object not found, ec info provided")`, but it's introduced as complex type with data within

elebedeva marked this conversation as resolved