Open SergeyKleyman opened 5 years ago
The DiagnosticListener seems to assume that ProcessExceptionEvent is always an exception. This isn't really the case when the response is a status code (400 bad request etc)
Also found in my testing that the transaction is null inside the ProcessExceptionEvent method
@maverix I'm not sure if the issue you are reporting is the same as this one so I've created a separate issue (#302) - let's continue our investigation there. If it turns out that the issues are the same we can always merge them back later. Is it okay with you?
@SergeyKleyman I'm sorry for the delay (you must get that a lot). I have since removed the use of the IDiagnosticListener and created my own handlers for HttpClient and API pipeline. These are working well
Bigger problem: we only receive the start event and we create a span for that and store the request - problem is we don't get any event for the exception or end. Probably as the 1. step we should make sure we don't cause too much memory usage due to this.
For example, when testing
/Home/FailingOutGoingHttpCall
ofsample\AspNetFullFrameworkSampleApp
(the issue is reproducible both when the application running on top of IIS and IIS Express).It seems that in that case
IDiagnosticListener
on .NET Framework doesn't receive HTTP-request-failed event as it does happen on .NET Core.In
/Home/FailingOutGoingHttpCall
HTTP call fails because host name is nonexistent, i.e., DNS resolution failure - we also need to cover cases when HTTP call fails because it's timed out and/or server forcibly closed connection. elastic/apm-agent-dotnet#293 is the issue to implement the same kind of tests for .NET Core.