Describe the bug
We are using a custom composition class which inherits/overrides from System.Net.WebRequest (which basically contains the original HttpWebRequest) in order to set service names to specific URIs.
I know this sounds like a dirty approach. But this worked pretty well for us, since we can not implement tracing on the external services itself.
This was working fine with 1.17 and prior.
Version 1.19.1 (and possible prior versions) broke this approach.
Throwing an exception when returning/trying to cast our Services.CompositionHttpWebRequest object:
2020-08-12 17:32:44.388 +02:00 [INF] DATADOG TRACER CONFIGURATION - {"date":"2020-08-12T17:32:44.3881148+02:00","os_name":"Windows","os_version":"Microsoft Windows NT 10.0.17763.0","version":"1.19.1.0","platform":"x64","lang":".NET Framework","lang_version":"4.8","env":"dev","enabled":true,"service":"xxxxxxx","agent_url":"http://localhost:8126","debug":false,"analytics_enabled":true,"sample_rate":null,"sampling_rules":null,"tags":[],"log_injection_enabled":true,"runtime_metrics_enabled":false,"disabled_integrations":[],"agent_reachable":false,"agent_error":"Unable to cast object of type 'Services.CompositionHttpWebRequest' to type 'System.Net.HttpWebRequest'."}
{ MachineName: ".", Process: "[4388 w3wp]", AppDomain: "[3 /LM/W3SVC/1/ROOT-2-132417199639835042]", TracerVersion: "1.19.1.0" }
2020-08-12 17:33:00.536 +02:00 [ERR] An unhandled error occurred during the flushing task
System.InvalidCastException: Unable to cast object of type 'Services.CompositionHttpWebRequest' to type 'System.Net.HttpWebRequest'.
at Datadog.Trace.Agent.ApiWebRequestFactory.Create(Uri endpoint)
at Datadog.Trace.Agent.Api.<SendTracesAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
at Datadog.Trace.Agent.AgentWriter.<FlushTracesAsync>d__12.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at Datadog.Trace.Agent.AgentWriter.<FlushTracesTaskLoopAsync>d__13.MoveNext()
{ MachineName: ".", Process: "[4388 w3wp]", AppDomain: "[3 /LM/W3SVC/1/ROOT-2-132417199639835042]", TracerVersion: "1.19.1.0" }
public class WebRequestModule2 : IWebRequestCreate
{
public WebRequest Create(Uri uri)
{
CompositionHttpWebRequest webRequest = new CompositionHttpWebRequest(uri);
return webRequest;
}
}
Maybe there is a better solution to set ServiceNames (on spans) for specific URIs which can intercept those WebRequests - without using manual span instrumentation everywhere - where those webservices are getting consumed.
Thank you for any help or ideas to work this out.
If you need more details (code, logs, etc.), just let me know.
Expected behavior
Behavior like 1.17 - when this approach worked. Or a better solution to tag or set service names on WebRequests.
Runtime environment (please complete the following information):
- Instrumentation mode: automatic and manual (IIS)
- Tracer version: 1.19.1
- OS: Windows Server 2019
- CLR: .NET Framework 4.8
Describe the bug
We are using a custom composition class which inherits/overrides from System.Net.WebRequest (which basically contains the original HttpWebRequest) in order to set service names to specific URIs.
I know this sounds like a dirty approach. But this worked pretty well for us, since we can not implement tracing on the external services itself.
This was working fine with 1.17 and prior.
Version 1.19.1 (and possible prior versions) broke this approach.
Throwing an exception when returning/trying to cast our
Services.CompositionHttpWebRequestobject:Maybe there is a better solution to set ServiceNames (on spans) for specific URIs which can intercept those WebRequests - without using manual span instrumentation everywhere - where those webservices are getting consumed.
Thank you for any help or ideas to work this out.
If you need more details (code, logs, etc.), just let me know.
Expected behavior
Behavior like 1.17 - when this approach worked. Or a better solution to tag or set service names on WebRequests.
Runtime environment (please complete the following information):