-
Notifications
You must be signed in to change notification settings - Fork 205
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
Log ingestion error on 206 response #2065
Conversation
if you hide whitespace in the diff it will help |
...c/main/java/com/microsoft/applicationinsights/agent/internal/telemetry/TelemetryChannel.java
Show resolved
Hide resolved
case 408: // REQUEST TIMEOUT | ||
case 500: // INTERNAL SERVER ERROR | ||
case 503: // SERVICE UNAVAILABLE | ||
case 429: // TOO MANY REQUESTS | ||
// TODO (heya) should we write to disk on any of these response codes? |
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.
not sure... if we don't write to disk, we should consider tracking how many requests we drop. Let's think about it.. need to come up with new property in customdimension.. it can be part of network statsbeat..
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.
can you update the todo to track data drop via statsbeat?
...c/main/java/com/microsoft/applicationinsights/agent/internal/telemetry/TelemetryChannel.java
Show resolved
Hide resolved
case 408: // REQUEST TIMEOUT | ||
case 429: // TOO MANY REQUESTS | ||
case 500: // INTERNAL SERVER ERROR | ||
case 503: // SERVICE UNAVAILABLE | ||
operationLogger.recordFailure( | ||
"received response code " | ||
+ statusCode | ||
+ " (telemetry will be stored to disk and retried later)"); | ||
onFailure.accept(true); | ||
break; |
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.
this is the list of response codes that 2.x used to retry on, I think it's a good list, not sure when we diverged from it
Related to #2064, which we never noticed since we didn't log it.
Now the error in #2064 would be logged as: