[#16] pool: Fix counting context canceled error #43

Merged
Member

Don't count wrapped grpc context canceled error and regular context canceled errors

Don't count wrapped grpc context canceled error and regular context canceled errors
dkirillov self-assigned this 2023-03-29 10:22:55 +00:00
dkirillov requested review from storage-core-committers 2023-03-29 10:23:03 +00:00
dkirillov requested review from storage-core-developers 2023-03-29 10:23:03 +00:00
dkirillov requested review from storage-services-committers 2023-03-29 10:23:03 +00:00
dkirillov requested review from storage-services-developers 2023-03-29 10:23:04 +00:00
fyrchik approved these changes 2023-03-29 11:31:51 +00:00
dkirillov force-pushed feature/16-dont_count_context_canceled_as_error from 4bec3e8f25 to c68df552a2 2023-03-29 11:56:28 +00:00 Compare
dkirillov requested review from fyrchik 2023-03-29 11:59:15 +00:00
alexvanin reviewed 2023-03-29 12:47:55 +00:00
pool/pool.go Outdated
@ -1027,4 +1025,1 @@
// we can't use errors.Is(err, context.Canceled)
// https://github.com/grpc/grpc-go/issues/4375
return status.Code(err) != codes.Canceled
Owner

Is it covered with errors.Is(ctx.Err(), context.Canceled)?

Is it covered with `errors.Is(ctx.Err(), context.Canceled)`?
Author
Member

In case of client canceling - yes.
As I understand we want to handle client canceling and not inner timeout/deadling/canceling. Am I wrong?

In case of client canceling - yes. As I understand we want to handle client canceling and not inner timeout/deadling/canceling. Am I wrong?
dkirillov force-pushed feature/16-dont_count_context_canceled_as_error from c68df552a2 to 552219b8e1 2023-03-29 12:58:13 +00:00 Compare
dstepanov-yadro reviewed 2023-03-29 15:09:46 +00:00
@ -1028,3 +1026,1 @@
// we can't use errors.Is(err, context.Canceled)
// https://github.com/grpc/grpc-go/issues/4375
return status.Code(err) != codes.Canceled
if errors.Is(ctx.Err(), context.Canceled) {

Why condition status.Code(err) != codes.Canceled dropped? As I understand it, the type of error depends on where the cancellation event is handled. For example, this function wraps ctx.Done() to status.Status with status.Code(err) == codes.Canceled

Why condition ```status.Code(err) != codes.Canceled``` dropped? As I understand it, the type of error depends on where the cancellation event is handled. For example, [this function](https://github.com/grpc/grpc-go/blob/master/clientconn.go#L577) wraps ctx.Done() to status.Status with ```status.Code(err) == codes.Canceled```
Author
Member

If we want to handle only client canceling we can rely on error in context. Error in context will be context.Canceled no matter what error will be returned from sdk client

If we want to handle only client canceling we can rely on error in context. Error in context will be `context.Canceled` no matter what error will be returned from sdk client
dstepanov-yadro approved these changes 2023-03-30 06:57:24 +00:00
alexvanin approved these changes 2023-03-30 12:42:10 +00:00
alexvanin merged commit 552219b8e1 into master 2023-03-30 12:42:17 +00:00
alexvanin deleted branch feature/16-dont_count_context_canceled_as_error 2023-03-30 12:42:18 +00:00
Sign in to join this conversation.
No reviewers
TrueCloudLab/storage-services-developers
No milestone
No project
No assignees
4 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#43
No description provided.