Reorganize handleError logic in pool #12

New issue

Open

opened 2023-01-23 08:11:54 +00:00 by alexvanin · 2 comments

alexvanin commented

2023-01-23 08:11:54 +00:00

(Migrated from github.com)

We have a bit of a hacks in handleError after https://github.com/TrueCloudLab/frostfs-sdk-go/pull/11: split info error should be passed as a status code from FrostFS but returned as a generic error anyway.

Consider making changes in API and storage node to avoid having split info error in transport error layer.
Or consider making handleError function parsing only error type without working with any statuses, so it will be at least consistent.

We have a bit of a hacks in `handleError` after https://github.com/TrueCloudLab/frostfs-sdk-go/pull/11: split info error should be passed as a status code from FrostFS but returned as a generic error anyway. Consider making changes in API and storage node to avoid having split info error in transport error layer. Or consider making `handleError` function parsing only `error` type without working with any statuses, so it will be at least consistent.

fyrchik added the

pool

label 2023-05-02 07:56:35 +00:00

alexvanin self-assigned this 2023-06-01 06:54:10 +00:00

alexvanin commented

2023-09-20 14:03:29 +00:00

Owner

@dkirillov Can you check if this still relevant?

👍 1

alexvanin removed their assignment 2023-09-20 14:03:37 +00:00

dkirillov was assigned by alexvanin

2023-09-20 14:03:37 +00:00

dkirillov commented

2023-09-21 06:51:14 +00:00

Member

The current behavior the same as it was. We have to check if generic error is split info error in handleError.
To fix this we can change only sdk (not api/node) because node doesn't return error at all in such case. We form split error here.

But do we really want such changes? If the question is only in the consistency in handleError then it seems we will still have it because of checking context.Cancelled error here

The current behavior the same as it was. We have to check if generic error is split info error in `handleError`. To fix this we can change only sdk (not api/node) because node doesn't return error at all in such case. We form split error [here](https://git.frostfs.info/TrueCloudLab/frostfs-sdk-go/src/commit/99c273f4993b8fe6b8e98782bb61554416912c5c/client/object_get.go#L504). But do we really want such changes? If the question is only in the consistency in `handleError` then it seems we will still have it because of checking `context.Cancelled` error [here](https://git.frostfs.info/TrueCloudLab/frostfs-sdk-go/src/commit/99c273f4993b8fe6b8e98782bb61554416912c5c/pool/pool.go#L1122)