-
Notifications
You must be signed in to change notification settings - Fork 580
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
Retry GoogleDataTransport Connection Errors #1705
Conversation
Binary Size ReportAffected SDKs
Test Logs
NotesHead commit (94d853c7) is created by Prow via merging commits: 037282f e2af542. |
Coverage ReportAffected SDKs
Test Logs
NotesHTML coverage reports can be produced locally with Head commit (94d853c7) is created by Prow via merging commits: 037282f e2af542. |
/test smoke-tests |
Links were super helpful. This would result in retrying ? What am i missing |
@ashwinraghav The issue is IOException from this error don't bubble up to that So when this error happens that we are testing, we get a valid response here. And then it becomes a fatalError here before, because it was a 400. Not since we return a |
Makes sense. |
Can you add a test similar to Line 299 in 0ecb114
|
@@ -268,6 +270,9 @@ private HttpResponse doSend(HttpRequest request) throws IOException { | |||
// JsonWriter often writes one character at a time. | |||
dataEncoder.encode( | |||
request.requestBody, new BufferedWriter(new OutputStreamWriter(outputStream))); | |||
} catch (ConnectException | UnknownHostException e) { |
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.
Thinking out loud: This seems like a pretty conservative approach, as opposed to treating all IO Exceptions as retry-able.
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.
Yeah exactly - the reason we did this is there are legit IO Exceptions that would not be retryable, eg. encoding errors of some sort
@ashwinraghav we tried to write a test, but it seems really difficult with the current code setup, and with WireMock. We're gonna punt for now and sync up with Vlad on Friday to see if he knows a way. |
In cases where there is bad connection, the current behavior deletes the cached reports because they are caught as an
IOException
. They appear to be encoding errors, when in reality it's an error opening theOutputStream
that is the connection.This changes it so that when the
IOException
is due to connection problems, we retry the upload instead of deleting it.This is where we transform status numbers into success, fatal, and transient errors: CctTransportBackend.java
This is where we decide to delete fatal errors, and retry transient errors: Uploader.java