[#16] pool: Fix counting context canceled error #43
No reviewers
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
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-sdk-go#43
Loading…
Reference in a new issue
No description provided.
Delete branch "dkirillov/frostfs-sdk-go:feature/16-dont_count_context_canceled_as_error"
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?
Don't count wrapped grpc context canceled error and regular context canceled errors
4bec3e8f25
toc68df552a2
@ -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
Is it covered with
errors.Is(ctx.Err(), context.Canceled)
?In case of client canceling - yes.
As I understand we want to handle client canceling and not inner timeout/deadling/canceling. Am I wrong?
c68df552a2
to552219b8e1
@ -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 withstatus.Code(err) == codes.Canceled
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