-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Context cancellation error sometimes swallowed by Client.listObjectsV2 #1850
Comments
Thanks will take a look @56quarters |
@56quarters looking at this if the context was canceled by the caller what we are expecting is that the caller is no longer interested in the which would mean that we simply return with no error, since it is not an error condition as such because it is the caller who decided to cancel the list. does it make sense? |
We can't safely write to the channel because the caller might have decided to not read anymore which can end up blocking the call. Think of this like So we can't expect the caller to be available to read the "error". The bug is actually correctly fixed in Thanos project thanos-io/objstore#62 |
Please try with #1852 |
Thanks! I'll give this a shot tomorrow. |
So I decided against it after some discussions, context errors are actually not actually the responsibility to be bubbled up via objectInfoCh and it cannot be safely done. |
OK, that rationale makes sense to me. Thank you for taking a look! What do you think about mentioning this in the API docs for |
Actually found a way to make sure this is honored. @56quarters |
Looks great, thank you! |
Hello MinIO folks!
I work on the Mimir project. We make use of a library from Thanos for access to object storage that in turn uses MinIO for S3 interactions. I've run into something surprising when using the
Client.ListObjects
method. I'm not sure if this is a bug or working as expected. The summary is that depending on when exactly thecontext.Context
passed toClient.ListObjects
is cancelled, sometimes the channel fromListObjects
returns noObjectInfo
results and noObjectInfo.Err
error. Other times, it returns anObjectInfo.Err
error.Consider the following code to recreate the issue. This is mean to represent a process being in the middle of making a
Client.ListObjects
call when the process is stopped.Expected behavior
Assuming that listing the objects in the directory takes longer than
5ms
, I would expectClient.ListObjects
to send thectx.Err()
error ifctx.Done()
is true/closed.Actual behavior
Depending on when the cancellation takes place, it's possible that no
ObjectInfo.Err
is returned. This can be mitigated by checking for cancellation in the caller ofClient.ListObjects
. Indeed, this is the solution we went with in the Thanos objstore library.What I would like
Can you confirm that not sending
ctx.Err()
via the results channel is on purpose or is an oversight? If this is expected behavior, could the fact that the context cancellation error is not propagated be documented as part of the API docs?References
Thanks!
The text was updated successfully, but these errors were encountered: