-
Notifications
You must be signed in to change notification settings - Fork 452
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
Swallow exception from close call when there is an underlying IOException #333
Conversation
This makes the code more consistent with the example on Closeables#closeQuietly javadoc
@chajath any updates on this? We are seeing some Dataflow customers facing issues where they cannot debug the underlying exception thrown? Do you know when will this be released? |
I haven't heard anything back yet. I will follow up with the team if I don't hear back soon. |
As a Dataflow customer we would really love to see some progress on this (: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#337 should be fixing the Travis failure.
There's also #334 that I've opened that should fix the build. |
Thanks, looking forward to the fix. I'm the Dataflow user. This fix will help us debug what is happening in the my Pipeline --- at the moment, there is no info on what is making it fail. |
* updated versions.txt [ci skip] * updated appengine/pom.xml [ci skip] * updated bom/pom.xml [ci skip] * updated credentials/pom.xml [ci skip] * updated oauth2_http/pom.xml [ci skip] * updated pom.xml [ci skip]
There have been numerous reports of users of the client library seeing IO exceptions bearing the message "insufficient data written" (googleapis/google-api-java-client#781 googleapis/google-api-java-client#782 googleapis/google-cloud-java#1018)
I believe these error messages are misleading, and are secondary effect of attempting to close the stream when the underlying IO operation was actually failing (see underlying close implementation)
Therefore I propose we handle the case when there has been an underlying IO exception error, we still attempt to close the stream but let the original IO exception propagate nonetheless.