You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What's Working:
I have a web application. It has an Angular (version 14) client-side and Play framework server-side. I have followed the directions in Datadog's documentation for connecting RUM and traces. The end-to-end trace is working (with the relevant X-Datadog-* headers being sent) for the requests made via the fetch function (located in node_modules/typescript/lib/lib.dom.d.ts).
What's Not Working:
But the majority of the requests the Angular app makes to my server are via the HttpClient in node_modules/@angular/common/http/index.d.ts. None of those requests are being traced end-to-end because the relevant X-Datadog-* headers are not being injected in them. I also have some HttpInterceptors, so I thought perhaps one of them might be stripping out these headers. But the X-Datadog-* headers never seem to have been injected at all (they're never present even at the beginning of any interceptor's intercept function). This is despite the server's responses' Access-Control-Allow-Headers headers always including the headers "X-Datadog-Trace-Id", etc.
Attempted Solutions:
I'm guessing perhaps the Datadog RUM SDK's header-injection logic and Angular HttpClient's dealing with requests' headers are conflicting somehow. But I don't know how to fix it. I've tried with @datadog/browser-rum versions 5.13.0 and 5.15.0. I've also tried doing datadogRum.init() as the first thing in main.ts as well as in the ngOnInit() function of app.component.ts.
The text was updated successfully, but these errors were encountered:
Hello @playtowork,
Thank you for your feedback. I wasn't able to reproduce the issue locally; I can see the header when using HttpClient.
Can you confirm that the allowedTracingUrls is well configured? If yes, could you provide a minimal reproducible example?
You can also contact our support to provide more details. They will be able to assist you in identifying the problem.
do you happen to be using pace.js in your frontend app? i encountered this issue too, turns out there's a bug that overrides XMLHttpRequest.prototype to an empty object. The Datadog browser SDK adds the headers by wrapping the prototype's methods. Removing this dependency worked for me CodeByZach/pace#261
Hello,
We haven't heard back from you @playtowork in a while, so we're going to close this issue for now. If you still need help or have further information to provide, please feel free to reopen the issue or create a new one. We appreciate your understanding.
What's Working:
I have a web application. It has an Angular (version 14) client-side and Play framework server-side. I have followed the directions in Datadog's documentation for connecting RUM and traces. The end-to-end trace is working (with the relevant
X-Datadog-*
headers being sent) for the requests made via thefetch
function (located innode_modules/typescript/lib/lib.dom.d.ts
).What's Not Working:
But the majority of the requests the Angular app makes to my server are via the
HttpClient
innode_modules/@angular/common/http/index.d.ts
. None of those requests are being traced end-to-end because the relevantX-Datadog-*
headers are not being injected in them. I also have someHttpInterceptor
s, so I thought perhaps one of them might be stripping out these headers. But theX-Datadog-*
headers never seem to have been injected at all (they're never present even at the beginning of any interceptor's intercept function). This is despite the server's responses'Access-Control-Allow-Headers
headers always including the headers "X-Datadog-Trace-Id", etc.Attempted Solutions:
I'm guessing perhaps the Datadog RUM SDK's header-injection logic and Angular
HttpClient
's dealing with requests' headers are conflicting somehow. But I don't know how to fix it. I've tried with@datadog/browser-rum
versions5.13.0
and5.15.0
. I've also tried doingdatadogRum.init()
as the first thing inmain.ts
as well as in thengOnInit()
function ofapp.component.ts
.The text was updated successfully, but these errors were encountered: