-
Notifications
You must be signed in to change notification settings - Fork 287
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
Unncessary response deserializations in PartialSuccessTransmissionPolicy for ingestion sampling cases #2445
Comments
We do the deserialization and other checks like error.Index >= items.Length once we confirm that this is due to a retryable error. Please let me know if there is some case I am missing else I can send out a PR |
I am not sure what is the bug here.
|
@cijothomas my understanding is that PartialSuccessTransmissionPolicy is for the cases when response is 206, but the underlying error (which is present in the response.Errors[i].statusCode) is amongst the retryable error status codes like 503, 429, 408 etc. When server side ingestion is turned on, we get a 206 from the server, but the response payload looks like this: In such cases we do not need to deserialize the response object because we can examine that response.Errors[i].statusCode == 206 and in such cases skip deserializing the initialTransmission.Content completely. |
@TimothyMothra @cijothomas have submitted a PR for this, please take a look |
*.csproj
file): netcoreapp3.1Describe the bug
Due to the way the code at
ApplicationInsights-dotnet/BASE/src/ServerTelemetryChannel/Implementation/TransmissionPolicy/PartialSuccessTransmissionPolicy.cs
Lines 49 to 58 in 6b5fcd8
To Reproduce
In your AI resource just turn on ingestion side sampling to a relatively high degree and collect a memory dump using Perfview etc.
The text was updated successfully, but these errors were encountered: